RESOLVED FIXED Bug 78498
[chromium] Set opaque flag on SkBitmap in per-tile layer updater
https://bugs.webkit.org/show_bug.cgi?id=78498
Summary [chromium] Set opaque flag on SkBitmap in per-tile layer updater
Dana Jansens
Reported 2012-02-13 08:05:16 PST
[chromium] Set opaque flag on SkBitmap in per-tile layer updater
Attachments
Patch (2.94 KB, patch)
2012-02-13 08:06 PST, Dana Jansens
no flags
Patch (2.90 KB, patch)
2012-02-13 10:47 PST, Dana Jansens
no flags
Dana Jansens
Comment 1 2012-02-13 08:06:21 PST
Dana Jansens
Comment 2 2012-02-13 08:58:43 PST
Provide opaque information to skia so it can perform optimizations now or in the future.
Stephen White
Comment 3 2012-02-13 09:00:49 PST
Comment on attachment 126773 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=126773&action=review > Source/WebCore/platform/graphics/chromium/SkPictureCanvasLayerTextureUpdater.h:52 > + virtual void setOpaque(bool); > + Out of curiosity, why does this need to be public now? It doesn't seem to be called from anywhere new.
Dana Jansens
Comment 4 2012-02-13 09:03:00 PST
Comment on attachment 126773 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=126773&action=review >> Source/WebCore/platform/graphics/chromium/SkPictureCanvasLayerTextureUpdater.h:52 >> + > > Out of curiosity, why does this need to be public now? It doesn't seem to be called from anywhere new. It should have been public to start with. The function its overriding in LayerTextureUpdater.h is public.
Stephen White
Comment 5 2012-02-13 09:41:00 PST
Comment on attachment 126773 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=126773&action=review Looks good. r=me >>> Source/WebCore/platform/graphics/chromium/SkPictureCanvasLayerTextureUpdater.h:52 >>> + >> >> Out of curiosity, why does this need to be public now? It doesn't seem to be called from anywhere new. > > It should have been public to start with. The function its overriding in LayerTextureUpdater.h is public. Ah, thanks for the explanation.
Mike Reed
Comment 6 2012-02-13 10:10:36 PST
probably better to set the opaqueness *after* the call to allocPixels(). I think this may work today, but it is likely we'll want to pass this hint onto the pixelref, which we don't have until the alloc call.
Dana Jansens
Comment 7 2012-02-13 10:20:53 PST
Would the bitmap not pass the current isOpaque() value on to the pixelref when the pixelref becomes available?
Mike Reed
Comment 8 2012-02-13 10:29:21 PST
it may. I am just thinking about future evolution of the API.
Dana Jansens
Comment 9 2012-02-13 10:47:39 PST
Created attachment 126795 [details] Patch reversed the call order to skbitmap as per @reed's comments.
noel gordon
Comment 10 2012-02-13 21:24:48 PST
Kinda reminds me of http://crbug.com/113171, where calling setIsOpaque() on bitmap lead to all sorts of trouble. Maybe I worry too much?
WebKit Review Bot
Comment 11 2012-02-13 21:57:42 PST
Comment on attachment 126795 [details] Patch Clearing flags on attachment: 126795 Committed r107669: <http://trac.webkit.org/changeset/107669>
WebKit Review Bot
Comment 12 2012-02-13 21:57:47 PST
All reviewed patches have been landed. Closing bug.
Dana Jansens
Comment 13 2012-02-14 07:54:12 PST
Looks like a fun bug. I think we'll be okay. We fill the bitmap with things before using the pixels here, as they are used for texture upload.
noel gordon
Comment 14 2012-02-14 18:04:21 PST
Yeah fun bug, and very glad to hear you don't have it :)
Note You need to log in before you can comment on or make changes to this bug.