[webkit-reviews] review canceled: [Bug 74352] [skia] Track a simple opaque area when painting via PlatformContextSkia and save in LayerTextureUpdater : [Attachment 120047] Patch

[bugzilla-daemon at webkit.org]

Dana Jansens <danakj at chromium.org> has canceled Dana Jansens
<danakj at chromium.org>'s request for review:
Bug 74352: [skia] Track a simple opaque area when painting via
PlatformContextSkia and save in LayerTextureUpdater
https://bugs.webkit.org/show_bug.cgi?id=74352

Attachment 120047: Patch
https://bugs.webkit.org/attachment.cgi?id=120047&action=review

------- Additional Comments from Dana Jansens <danakj at chromium.org>
(In reply to comment #36)
> Simple is good but I'm not sure what you're suggesting simple will be in this
case. I mostly want to make sure that whatever we do produces a reasonably good
indication of the areas of the layer are opaque. Depending on the order that
paints happen in WebKit we could either end up with a good approximation or an
overly conservative one.  For example, how does WebKit paint a layer with a
semi-transparent border?  How about a layer that contains a number of opaque
elements next to each other but has no opaque background? Will they be drawn in
a way that will let us concatenate their rects into a larger rect?

Ok here are some much-needed numbers.  I ran all of the compositing layout
tests, and I am ignoring scroll bars (they are drawn in Chrome).

The average number of opaque pixels that we find, per layer = 83.6%
The total number of opaque pixels that we find, over all the tests = 73.2%

On most layers it is getting most of the pixels. The times it misses most are
layers with opaque borders but non-opaque interiors.

This seems like a pretty decent first step towards deciding opaque-ness, and it
is something we can iterate on in the future to improve.

I will throw up a new patch tomorrow.