Make sure pictures draw Clears even when the clip is empty.

Make sure pictures draw Clears even when the clip is empty.

We fix this by rewriting empty queries to very tiny queries, which will certainly
hit ops that span the entire picture (like Clear) and hopefully not much more.

(This doesn't quite work in the full cull rect world if [0,0,ε,ε] doesn't
overlap the picture.  Let's cross that bridge when we get there.)

BUG=432991
Committed: https://skia.googlesource.com/skia/+/7cc1a34fbf5506e3a9e6834f0dcd988aa7c94084

[mtklein_C, 2014-11-19 21:59:44]

mtklein@chromium.org changed reviewers:
+ junov@chromium.org, robertphillips@google.com

[mtklein_C, 2014-11-19 21:59:45]

C.f. https://code.google.com/p/chromium/issues/detail?id=432991, #23-#30.

I'm not convinced this is actually related to the underlying bug there, but at
least
this explains why I wrote this CL.

[Justin Novosad, 2014-11-19 22:22:26]

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

https://codereview.chromium.org/732723004/diff/60001/src/core/SkRecordDraw.cp...
src/core/SkRecordDraw.cpp:29: query = SkRect::MakeWH(SK_ScalarNearlyZero,
SK_ScalarNearlyZero);
Having content at 0,0 is common, if you positioned the rectangle at a far away
negative x/y position you would be less likely to accidentally hit ordinary
content IMHO.

[mtklein, 2014-11-19 23:07:26]

> Having content at 0,0 is common, if you positioned the rectangle at a far away
> negative x/y position you would be less likely to accidentally hit ordinary
> content IMHO.

Let's try this.  As we've got the code written, a Clear's bounds is the cull
rect of the picture, which is typically [0,0,N,M], so without changing that, we
need our tiny query here to be in the positive quarter.  I don't think this is
likely to cause any noticeable performance problem.  Other non-Clear draws that
we happen to hit will be very quickly rejected by SkCanvas as no-ops when
there's an empty clip.

If one day we find ourselves really caring this performs as well as it can
(rather than just being correct), we can try moving the query to something like
[0xff7fffff, 0xff7fffff, 0xff7ffffe, 0xff7ffffe], but that'll require we also
inflate the bounds of clears() (and all structural commands above them) out to
SkRect::MakeLargest().  I want to stay away from that as long as possible, as
it's nice to work with the most precise bounds we can get, and clearly
SkRect::MakeLargest() is not very precise.

Ideally I'd like to find a tiny spot to query that's in the picture and doesn't
hit anything but Clears, but in the picture seems enough for drawing
correctness.

[Justin Novosad, 2014-11-19 23:30:55]

lgtm

[mtklein, 2014-11-20 15:46:25]

On 2014/11/19 23:30:55, junov wrote:
> lgtm

So, after we realized that the problem was a SkCanvas subclass yesterday, I do
think this CL will probably fix the Chrome issue.  Yesterday's revert won't,
because we also switched from SkTileGrid to SkRTree during that time period, and
SkRTree really needs this CL.

I've rewritten the test to use another SkPicture as its target canvas rather
than a bitmap-backed SkCanvas.  This decouples this CL from the other one that
actually fixes SkCanvas.

[mtklein, 2014-11-20 15:51:30]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-11-20 15:52:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/732723004/80001

[commit-bot: I haz the power, 2014-11-20 16:01:14]

Committed patchset #5 (id:80001) as
https://skia.googlesource.com/skia/+/7cc1a34fbf5506e3a9e6834f0dcd988aa7c94084