allow canvas to force conservative clips (for speed)

Allow SkCanvas to be initialized to force conservative rasterclips. This has the following effects:

1. Queries to the current clip will be conservatively large. This can mean the quickReject may return false more often.

2. The conservative clips mean less work is done.

3. Enabled by default for Gpu, Record, and NoSaveLayer canvases.

4. API is private for now.

Committed: https://skia.googlesource.com/skia/+/27a5e656c3d6ef22f9cb34de18e1b960da3aa241

[reed1, 2014-09-08 21:37:26]

reed@google.com changed reviewers:
+ bsalomon@google.com, mtklein@google.com, robertphillips@google.com

[reed1, 2014-09-08 21:37:27]

the rasterclip changes seem to be correct.

However, what is the best way to "trigger" this new behavior?

This CL lays the burden on the device subclass (ala GPU). However, this does not
automatically cover 
- NoSaveLayerCanvas
- PictureRecorder

1. Thought about a virtual on canvas, but as written I like to know the answer
inside init(), which is called by the base constructor.

2. Could be an explicit parameter passed to the canvas constructor (which,
fortuneately, is getting more private thanks to factories).

When I figure this part, I will benchmark both GPU and PictureRecord backends,
to be sure I improved (or at least didn't regress) either.

[reed1, 2014-09-09 16:34:32]

PTAL -- added flag to canvas for this behavior, but it is also deducible from
the device.

[mtklein, 2014-09-09 17:25:39]

I'm probably a bit behind on this... clients can't get at the clip anymore?

https://codereview.chromium.org/541593005/diff/100001/src/core/SkRasterClip.cpp
File src/core/SkRasterClip.cpp (right):

https://codereview.chromium.org/541593005/diff/100001/src/core/SkRasterClip.c...
src/core/SkRasterClip.cpp:116: //    
this->getDevice()->getGlobalBounds(&deviceIBounds);
stray?

https://codereview.chromium.org/541593005/diff/100001/src/core/SkRasterClip.c...
src/core/SkRasterClip.cpp:144: // should not get here
SkFAIL("should not get here")?

[reed1, 2014-09-09 17:41:38]

reed@google.com changed reviewers:
+ junov@google.com

[reed1, 2014-09-09 17:41:38]

https://codereview.chromium.org/541593005/diff/100001/src/core/SkRasterClip.cpp
File src/core/SkRasterClip.cpp (right):

https://codereview.chromium.org/541593005/diff/100001/src/core/SkRasterClip.c...
src/core/SkRasterClip.cpp:116: //    
this->getDevice()->getGlobalBounds(&deviceIBounds);
On 2014/09/09 17:25:38, mtklein wrote:
> stray?

Done.

https://codereview.chromium.org/541593005/diff/100001/src/core/SkRasterClip.c...
src/core/SkRasterClip.cpp:144: // should not get here
On 2014/09/09 17:25:38, mtklein wrote:
> SkFAIL("should not get here")?

Done.

[mtklein, 2014-09-09 17:51:52]

Brain fart!  LGTM.

[reed1, 2014-09-09 19:11:11]

The CQ bit was checked by reed@google.com

[commit-bot: I haz the power, 2014-09-09 19:11:45]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/reed@google.com/541593005/120001

[commit-bot: I haz the power, 2014-09-09 19:19:33]

Committed patchset #7 (id:120001) as 27a5e656c3d6ef22f9cb34de18e1b960da3aa241

[reed1, 2014-09-09 19:50:18]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/554033003/ by reed@google.com.

The reason for reverting is: multipicturedraw failed on nvprmsaa -- don't know
why yet.

[robertphillips, 2014-09-10 14:44:23]

https://codereview.chromium.org/541593005/diff/120001/src/core/SkRasterClip.cpp
File src/core/SkRasterClip.cpp (right):

https://codereview.chromium.org/541593005/diff/120001/src/core/SkRasterClip.c...
src/core/SkRasterClip.cpp:171: 
Subroutine for this and the version in SkRasterClip::op ?