Start filling BBH in SkRecordDraw.

Start filling BBH in SkRecordDraw.

This starts with a skeleton of how to calculate bounds for ops which don't have
their own bounds.  For any given Save/Restore block, we'll find the union of the
bounds of all the draws inside it (including other Save/Restore blocks), then say
those are the bounds of all non-draws in the block, including the Save and Restore.

To implement this, we keep a stack of active Save blocks.  Any time we hit a
non-drawing op ("control"), we'll add it to that Save block (implemented with a
separate stack of indices and a count of control ops in the entry on the Save
stack).  Save and SaveLayer push onto the stack, and Restore pops the stack, at
which point we can fill in the bounds for all the control ops in the block.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/828ce1f34b3471c108aee6ac2c39ddb90d0be11e

[robertphillips, 2014-08-13 18:53:47]

lgtm modulo documentation requests

https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
src/core/SkRecordDraw.cpp:97: // This is an SkRecord visitor that fills an
SkBBoxHierarchy.
// Every operation (including save* and control operations) gets a bounding box.

// For save* operations this is the bound of all the draw operations it
contains.
// For control operations this is the bound of the save* block in which they
reside.
// Due to this, the bounds of a save* operation isn't known until its matching
restore is encountered.

?

Maybe paste summary from the CL description here ?

https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
src/core/SkRecordDraw.cpp:168: SkIRect popSaveBlock() {
We're done _with_ ... ?

https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
src/core/SkRecordDraw.cpp:204: SkAutoTMalloc<SkIRect> fBounds;  // One for each
op in the record.
fI -> fCurOp, fCurBound, fCurOpIndex ?

https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
src/core/SkRecordDraw.cpp:205: unsigned fI;
// Contains both saves and saveLayers ?
fSaves -> fSaveStack ?

https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
src/core/SkRecordDraw.cpp:206: SkTDArray<SaveBounds> fSaves;
// A unified list of control operations encountered during rendering. Each save*
command keeps track of the control operation relevant to it (and updates and
pops them upon a restore).
fControls -> fControlIndices, fControlOpIndices ?

[mtklein, 2014-08-13 19:44:35]

On 2014/08/13 18:53:47, robertphillips wrote:
> lgtm modulo documentation requests
> 
> https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cpp
> File src/core/SkRecordDraw.cpp (right):
> 
>
https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
> src/core/SkRecordDraw.cpp:97: // This is an SkRecord visitor that fills an
> SkBBoxHierarchy.
> // Every operation (including save* and control operations) gets a bounding
box.
> 
> // For save* operations this is the bound of all the draw operations it
> contains.
> // For control operations this is the bound of the save* block in which they
> reside.
> // Due to this, the bounds of a save* operation isn't known until its matching
> restore is encountered.
> 
> ?
> 
> Maybe paste summary from the CL description here ?
> 
>
https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
> src/core/SkRecordDraw.cpp:168: SkIRect popSaveBlock() {
> We're done _with_ ... ?
> 
>
https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
> src/core/SkRecordDraw.cpp:204: SkAutoTMalloc<SkIRect> fBounds;  // One for
each
> op in the record.
> fI -> fCurOp, fCurBound, fCurOpIndex ?
> 
>
https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
> src/core/SkRecordDraw.cpp:205: unsigned fI;
> // Contains both saves and saveLayers ?
> fSaves -> fSaveStack ?
> 
>
https://codereview.chromium.org/475473002/diff/20001/src/core/SkRecordDraw.cp...
> src/core/SkRecordDraw.cpp:206: SkTDArray<SaveBounds> fSaves;
> // A unified list of control operations encountered during rendering. Each
save*
> command keeps track of the control operation relevant to it (and updates and
> pops them upon a restore).
> fControls -> fControlIndices, fControlOpIndices ?

All done.

[mtklein, 2014-08-13 19:45:02]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-08-13 19:45:54]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/mtklein@chromium.org/475473002/40001

[commit-bot: I haz the power, 2014-08-13 19:48:54]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  Build-Mac10.8-Clang-x86_64-Release-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Mac10.8-Clang-x86_64-Release-Trybo...)
  Build-Ubuntu13.10-Clang-x86_64-Debug-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Ubuntu13.10-Clang-x86_64-Debug-Try...)
  Build-Ubuntu13.10-GCC4.8-Arm7-Debug-Android-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Ubuntu13.10-GCC4.8-Arm7-Debug-Andr...)
  Build-Ubuntu13.10-GCC4.8-x86_64-Release-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Ubuntu13.10-GCC4.8-x86_64-Release-...)
  Build-Win-VS2013-x86-Debug-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Win-VS2013-x86-Debug-Trybot/builds...)
  Test-Ubuntu13.10-GCE-NoGPU-x86_64-Debug-Trybot on tryserver.skia
(http://108.170.220.120:10117/builders/Test-Ubuntu13.10-GCE-NoGPU-x86_64-Debug...)
  Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-Shared-Trybot on tryserver.skia
(http://108.170.220.120:10117/builders/Test-Ubuntu13.10-GCE-NoGPU-x86_64-Relea...)

[mtklein, 2014-08-13 19:50:13]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-08-13 19:50:14]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/mtklein@chromium.org/475473002/60001

[commit-bot: I haz the power, 2014-08-13 19:58:49]

Committed patchset #4 (60001) as 828ce1f34b3471c108aee6ac2c39ddb90d0be11e