RESOLVED FIXED 49560
[chromium] Avoid copying of SkBitmap in LayerRendererChromium 
https://bugs.webkit.org/show_bug.cgi?id=49560
Summary [chromium] Avoid copying of SkBitmap in LayerRendererChromium
Kenneth Russell
Reported Monday, November 15, 2010 9:12:26 PM UTC
Grace Kloba found that LayerRendererChromium was inadvertently causing a copy of the SkBitmap data structure for the root layer's canvas. If the bitmap is using an SkPixelRef internally, this can cause getPixels() to return NULL. The fix is to use a const SkBitmap& like ContentLayerChromium already does.
Attachments
Patch (1.41 KB, patch)
2010-11-15 13:14 PST, Kenneth Russell 		jamesr: review+
kbr: commit-queue-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Kenneth Russell
Comment 1 Monday, November 15, 2010 9:14:30 PM UTC
Created attachment 73925 [details] Patch
James Robinson
Comment 2 Monday, November 15, 2010 9:15:36 PM UTC
Comment on attachment 73925 [details] Patch Good catch!
Kenneth Russell
Comment 3 Monday, November 15, 2010 9:17:13 PM UTC
Committed r72026: <http://trac.webkit.org/changeset/72026>
Nico Weber
Comment 4 Tuesday, November 16, 2010 12:48:29 AM UTC
Accessing pixels() without calling lockPixels() isn't guaranteed to work.
James Robinson
Comment 5 Tuesday, November 16, 2010 12:57:23 AM UTC
Yeah, this really should call accessBitmap(true) as well, no?
Kenneth Russell
Comment 6 Tuesday, November 16, 2010 1:02:08 AM UTC
(In reply to comment #4) > Accessing pixels() without calling lockPixels() isn't guaranteed to work. This is definitely true for an ordinary SkBitmap, but what about the bitmaps that are managed by an SkDevice?
Kenneth Russell
Comment 7 Tuesday, November 16, 2010 1:02:34 AM UTC
(In reply to comment #5) > Yeah, this really should call accessBitmap(true) as well, no? No; the bitmap's pixels are only accessed to upload them to OpenGL, and aren't modified.
Note You need to log in before you can comment on or make changes to this bug.