Bug 76211 - [chromium] Enable tracking opaque region in Skia graphics context, return it from LayerTextureUpdater
Summary: [chromium] Enable tracking opaque region in Skia graphics context, return it ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dana Jansens
URL:
Keywords:
Depends on: 74352
Blocks: 76015
  Show dependency treegraph
 
Reported: 2012-01-12 14:00 PST by Dana Jansens
Modified: 2012-01-18 13:42 PST (History)
8 users (show)

See Also:


Attachments
Patch (12.63 KB, patch)
2012-01-12 14:10 PST, Dana Jansens
no flags Details | Formatted Diff | Diff
Patch (12.85 KB, patch)
2012-01-12 14:50 PST, Dana Jansens
no flags Details | Formatted Diff | Diff
Patch (27.10 KB, patch)
2012-01-14 07:07 PST, Dana Jansens
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dana Jansens 2012-01-12 14:00:47 PST
[chromium] Enable tracking opaque region in Skia graphics context and save it in LayerTextureUpdater after paint.
Comment 1 Dana Jansens 2012-01-12 14:10:34 PST
Created attachment 122308 [details]
Patch

- Compute an opaque area in the Skia graphics context when the layer isn't known to be fully opaque already.
- Save the opaque area given back by Skia's graphics context in the LayerTextureUpdater.
- Pass on the opaque() flag equally to all LayerTextureUpdaters for possible optimizations.
Comment 2 Dana Jansens 2012-01-12 14:11:54 PST
(EWS is going to fail until CQ lands #74352.)
Comment 3 WebKit Review Bot 2012-01-12 14:35:21 PST
Comment on attachment 122308 [details]
Patch

Attachment 122308 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11152216
Comment 4 Dana Jansens 2012-01-12 14:50:12 PST
Created attachment 122314 [details]
Patch

rebased
Comment 5 James Robinson 2012-01-13 15:29:55 PST
Comment on attachment 122314 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=122314&action=review

> Source/WebCore/platform/graphics/chromium/LayerTextureUpdater.h:81
> +    // A subset of the layer determined to be opaque during update. Not valid when setOpaque() has been set true,
> +    // as the output is already known to be opaque in that case.
> +    const IntRect& opaqueRect() const { return m_opaqueRect; }

this is a little weird. the way this works seems to be that every given call to prepareToUpdate() could potentially update this rectangle to be a part of the passed in contentRect, but the opaqueRect isn't valid for any future call to prepareToUpdate(). since we could call prepareToUpdate() many times on an updater with different content rects it seems like this would be better implemented as an output parameter to prepareToUpdate(). what would you think of that?

> Source/WebKit/chromium/tests/SkPictureCanvasLayerTextureUpdaterTest.cpp:68
> +    updater->prepareToUpdate(IntRect(0, 0, width, height), IntSize(width, height), 0, 1.0); \

just 1, not 1.0

> Source/WebKit/chromium/tests/SkPictureCanvasLayerTextureUpdaterTest.cpp:82
> +        Color opaque(1.0f, 0.0f, 0.0f, 1.0f);

WK style is (1, 0, 0, 1) or just (1, 0, 0). same goes for the rest of this file
Comment 6 Dana Jansens 2012-01-14 07:04:48 PST
Comment on attachment 122314 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=122314&action=review

>> Source/WebCore/platform/graphics/chromium/LayerTextureUpdater.h:81
>> +    const IntRect& opaqueRect() const { return m_opaqueRect; }
> 
> this is a little weird. the way this works seems to be that every given call to prepareToUpdate() could potentially update this rectangle to be a part of the passed in contentRect, but the opaqueRect isn't valid for any future call to prepareToUpdate(). since we could call prepareToUpdate() many times on an updater with different content rects it seems like this would be better implemented as an output parameter to prepareToUpdate(). what would you think of that?

yes absolutely. thanks. I added a rect to pass to prepareToUpdate() then, which is not used at all, as a local variable in prepareToUpdateTiles. Next CL will remove this as stated in the FIXME, just trying to keep CLs small.

>> Source/WebKit/chromium/tests/SkPictureCanvasLayerTextureUpdaterTest.cpp:68
>> +    updater->prepareToUpdate(IntRect(0, 0, width, height), IntSize(width, height), 0, 1.0); \
> 
> just 1, not 1.0

done.

>> Source/WebKit/chromium/tests/SkPictureCanvasLayerTextureUpdaterTest.cpp:82
>> +        Color opaque(1.0f, 0.0f, 0.0f, 1.0f);
> 
> WK style is (1, 0, 0, 1) or just (1, 0, 0). same goes for the rest of this file

oops, i tried 1.0 but ints (255) obviously work here, thanks.
Comment 7 Dana Jansens 2012-01-14 07:07:02 PST
Created attachment 122545 [details]
Patch

comments addressed.

- Since the opaqueRect is being returned from all texture updaters, I made BitmapCanvasLayerTextureUpdater compute the resultingOpaqueRect also.
Comment 8 Adrienne Walker 2012-01-17 11:49:49 PST
Comment on attachment 122545 [details]
Patch

This looks great to me.  :)
Comment 9 James Robinson 2012-01-17 13:15:20 PST
Comment on attachment 122545 [details]
Patch

R=me
Comment 10 WebKit Review Bot 2012-01-18 13:42:08 PST
Comment on attachment 122545 [details]
Patch

Clearing flags on attachment: 122545

Committed r105314: <http://trac.webkit.org/changeset/105314>
Comment 11 WebKit Review Bot 2012-01-18 13:42:18 PST
All reviewed patches have been landed.  Closing bug.