Alter clip stack plumbing - pass down new GrClipData class

This CL passes down the clip stack inside the new GrClipData class as a pointer (to remind everyone of the ephemeral nature of the clip data).

[robertphillips, 2012-07-26 15:25:01]

http://codereview.appspot.com/6454047/diff/19/include/gpu/SkGpuDevice.h
File include/gpu/SkGpuDevice.h (right):

http://codereview.appspot.com/6454047/diff/19/include/gpu/SkGpuDevice.h#newco...
include/gpu/SkGpuDevice.h:134: const SkClipStack*  fClipStack;
fGrClip is temporary until GrClipData absorbs fClipStack

http://codereview.appspot.com/6454047/diff/3001/include/gpu/SkGpuDevice.h
File include/gpu/SkGpuDevice.h (right):

http://codereview.appspot.com/6454047/diff/3001/include/gpu/SkGpuDevice.h#new...
include/gpu/SkGpuDevice.h:134: const SkClipStack*  fClipStack;
Note: fGrClip is now where the GrClip is stored until we switch over to using
SkClipStack directly.

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrTextContext.cpp
File src/gpu/GrTextContext.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrTextContext.cpp#new...
src/gpu/GrTextContext.cpp:87: 
Minor refactoring here to only call getConservativeBounds once

http://codereview.appspot.com/6454047/diff/3001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/SkGpuDevice.cpp#newco...
src/gpu/SkGpuDevice.cpp:354: // Canvas promises that this ptr is valid until
onDetachFromCanvas is called
fClipStack will be absorbed into fClipData here

[bsalomon, 2012-07-26 16:15:43]

http://codereview.appspot.com/6454047/diff/3001/include/gpu/GrClip.h
File include/gpu/GrClip.h (right):

http://codereview.appspot.com/6454047/diff/3001/include/gpu/GrClip.h#newcode215
include/gpu/GrClip.h:215: * with an offset bounding box. The clips in
'fClipStack' are not translated
The tense of this last sentence is a tiny bit unclear. At first I read it as
"will not be translated..." which is of course wrong.

http://codereview.appspot.com/6454047/diff/3001/include/gpu/GrClip.h#newcode231
include/gpu/GrClip.h:231: }
It's really starting to feel like clip stack needs to be refcounted, or is it?

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrAAHairLinePathRende...
File src/gpu/GrAAHairLinePathRenderer.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrAAHairLinePathRende...
src/gpu/GrAAHairLinePathRenderer.cpp:516: const GrClipData* clipData =
target->getClip();
If we start to see this pattern a lot it might be useful to have a
getConservativeBounds on either GrContext or GrClipData.

Do the bounds need to be transformed by the origin here?

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrClipMaskManager.cpp
File src/gpu/GrClipMaskManager.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrClipMaskManager.cpp...
src/gpu/GrClipMaskManager.cpp:154: GrRect conservativeBounds =
clipDataIn->fClipStack->getConservativeBounds();
same Q about bounds / origin

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrInOrderDrawBuffer.cpp
File src/gpu/GrInOrderDrawBuffer.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrInOrderDrawBuffer.c...
src/gpu/GrInOrderDrawBuffer.cpp:820: (fClips.back() != *fClip->fClipStack ||
I suppose we're keeping these separate so that we can record ops for them
independently later?

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrSoftwarePathRendere...
File src/gpu/GrSoftwarePathRenderer.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrSoftwarePathRendere...
src/gpu/GrSoftwarePathRenderer.cpp:51: SkRect conservativeBounds =
clipData->fClipStack->getConservativeBounds();
same bounds/origin q

[robertphillips, 2012-07-26 18:11:14]

http://codereview.appspot.com/6454047/diff/3001/include/gpu/GrClip.h
File include/gpu/GrClip.h (right):

http://codereview.appspot.com/6454047/diff/3001/include/gpu/GrClip.h#newcode215
include/gpu/GrClip.h:215: * with an offset bounding box. The clips in
'fClipStack' are not translated
Done - I originally wrote the comment in the CL in which fClipStack was a
SkClipStack*.

http://codereview.appspot.com/6454047/diff/3001/include/gpu/GrClip.h#newcode231
include/gpu/GrClip.h:231: }
I have made GrClipData non-copyable. Given where this is going I don't think
anyone (besides GrContext) will wind up with a persistent pointer to the
SkCanvas' SkClipStack.

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrAAHairLinePathRende...
File src/gpu/GrAAHairLinePathRenderer.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrAAHairLinePathRende...
src/gpu/GrAAHairLinePathRenderer.cpp:516: const GrClipData* clipData =
target->getClip();
I intend to add a helper function to GrClipData to encapsulate the call to
SkClipStack's getConservativeBounds call and perform the roundOut. I think only
GrTextContext will need to make a raw call to SkClipStack's
getConservativeBounds.

The bounds are transformed by the origin in SkClipStack's getConservativeBounds.
We're still dealing w/ GrClip's here.

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrInOrderDrawBuffer.cpp
File src/gpu/GrInOrderDrawBuffer.cpp (right):

http://codereview.appspot.com/6454047/diff/3001/src/gpu/GrInOrderDrawBuffer.c...
src/gpu/GrInOrderDrawBuffer.cpp:820: (fClips.back() != *fClip->fClipStack ||
Yep - the more I think about it the better of an idea that seems. There should
usually be far fewer origin changes and we might be able to do something else
with that state change (since it is on a saveLayer boundary).

[bsalomon, 2012-07-26 18:44:51]

LGTM

[robertphillips, 2012-07-26 18:52:47]

committed as r4788