stub for ganesh veto

stub for ganesh veto

BUG=skia:

Committed: http://code.google.com/p/skia/source/detail?r=13866

[humper, 2014-03-12 17:24:29]

Stub so we can agree on the API call and the Chrome side can plumb in the veto
check.

[nduca, 2014-03-12 17:36:15]

https://codereview.chromium.org/197803002/diff/1/include/core/SkPicture.h
File include/core/SkPicture.h (right):

https://codereview.chromium.org/197803002/diff/1/include/core/SkPicture.h#new...
include/core/SkPicture.h:233: bool suitableForGpuRasterization() const;
does this need to know the grcontext at some point? for instance, we'll want to
veto conical gradients on n10...

[bsalomon, 2014-03-12 17:43:22]

https://codereview.chromium.org/197803002/diff/1/include/core/SkPicture.h
File include/core/SkPicture.h (right):

https://codereview.chromium.org/197803002/diff/1/include/core/SkPicture.h#new...
include/core/SkPicture.h:233: bool suitableForGpuRasterization() const;
On 2014/03/12 17:36:15, nduca wrote:
> does this need to know the grcontext at some point? for instance, we'll want
to
> veto conical gradients on n10...

Yes, we'll want to know the capabilities present to make the decision.

[humper, 2014-03-12 17:52:04]

On 2014/03/12 17:43:22, bsalomon wrote:
> https://codereview.chromium.org/197803002/diff/1/include/core/SkPicture.h
> File include/core/SkPicture.h (right):
> 
>
https://codereview.chromium.org/197803002/diff/1/include/core/SkPicture.h#new...
> include/core/SkPicture.h:233: bool suitableForGpuRasterization() const;
> On 2014/03/12 17:36:15, nduca wrote:
> > does this need to know the grcontext at some point? for instance, we'll want
> to
> > veto conical gradients on n10...
> 
> Yes, we'll want to know the capabilities present to make the decision.

Good point.  GrContext argument added.

[bsalomon, 2014-03-12 20:51:09]

lgtm. I wonder if we will wind up requiring the playback matrix or clip, but
it's not obvious to me that it's useful now.

[nduca, 2014-03-12 21:07:53]

Key thing for you brian: this is going to get called in a critical path of
compositor, so one really needs to do the deciding of whether to veto by this
point --- by the time you get to this being called, the compositor is about to
rasterize and needs an answer, so walking the picture wont fly [we've seen that
take 1-2ms!]. That is, you'll probably need to compute various flags during
record (had_conical) and then just check them at the time of this call.

Does that change the shape of this API in any way? Would you instead want the
grcontext at construction time?

[nduca, 2014-03-12 22:54:31]

I tend to agree with the approach you suggest Greg --- construction is normal,
and you pass the context at the end, at query time, compute flags as you go. But
I just wanted to make sure we all were thinking that way, and that we all agreed
that this call cant walk the picture to determine the answer. :)

[bsalomon, 2014-03-13 12:35:39]

On 2014/03/12 21:07:53, nduca wrote:
> Key thing for you brian: this is going to get called in a critical path of
> compositor, so one really needs to do the deciding of whether to veto by this
> point --- by the time you get to this being called, the compositor is about to
> rasterize and needs an answer, so walking the picture wont fly [we've seen
that
> take 1-2ms!]. That is, you'll probably need to compute various flags during
> record (had_conical) and then just check them at the time of this call.
> 
> Does that change the shape of this API in any way? Would you instead want the
> grcontext at construction time?

The way I imagine it is that at record time (or a post record pass out of the
compositor's critical pass) gathers stats that might be relevant to any
GrContext. When this function is called we do a very quick test of the
GrContext's caps vs the gathered stats (without walking the skp). So, I don't
think we need to GrContext at record time. That might be a bit problematic
anyway as GrContext is not thread safe.

[humper, 2014-03-19 16:03:46]

The CQ bit was checked by humper@google.com

[commit-bot: I haz the power, 2014-03-19 16:03:53]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/humper@google.com/197803002/10001

[commit-bot: I haz the power, 2014-03-19 16:08:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-19 16:08:05]

Retried try job too often on Build-Ubuntu12-GCC-x86_64-Release-Trybot for
step(s) BuildBench, BuildEverything, BuildGm, BuildSkiaLib, BuildTests,
BuildTools
http://108.170.219.164:10117/buildstatus?builder=Build-Ubuntu12-GCC-x86_64-Re...

[humper, 2014-03-19 20:55:44]

The CQ bit was checked by humper@google.com

[commit-bot: I haz the power, 2014-03-19 20:55:46]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/humper@google.com/197803002/30001

[commit-bot: I haz the power, 2014-03-19 21:24:28]

Change committed as 13866

[bungeman-skia, 2014-03-19 22:03:21]

https://codereview.chromium.org/197803002/diff/30001/src/core/SkPicture.cpp
File src/core/SkPicture.cpp (right):

https://codereview.chromium.org/197803002/diff/30001/src/core/SkPicture.cpp#n...
src/core/SkPicture.cpp:454: bool
SkPicture::suitableForGpuRasterization(GrContext* context) const {
This impl also needs to be in #if SK_SUPPORT_GPU