[Webkit-unassigned] [Bug 106842] adding support for DiscardablePixelRef for caching lazily decoded images

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=106842





--- Comment #86 from Min Qin <qinmin at chromium.org>  2013-01-28 14:48:22 PST ---
(From update of attachment 185049)
View in context: https://bugs.webkit.org/attachment.cgi?id=185049&action=review

>> Source/WebCore/platform/graphics/chromium/DiscardablePixelRef.cpp:110
>> +    return false;
> 
> Could just be
> 
> return pixelRef && pixelRef->getURI() && discardable.equals(pixelRef->getURI())

Done.

>> Source/WebCore/platform/graphics/chromium/ImageDecodingStore.cpp:101
>> +        if (pixelRef->pixels()) {
> 
> I think you should check image->bitmap().pixels() here.  Once you've called lockPixels(), pixels() should be non-zero.  You shouldn't have to poke around into the pixelref to find out.

If i remember clearly, the reason i used this is because skBitmap::lockpixels() is not threadsafe. So after lockPixels(), I can get a NULL if I call getPixels().
But since all the cache entries are now protected by the mutex, we are safe to use getPixels（） instead of reading pixels from skPixelRef.

>> Source/WebCore/platform/graphics/chromium/ImageDecodingStore.cpp:116
>> +        }
> 
> Not new to this patch, but it seems really unfortunate to leave the pixels locked here, and require the caller to pair up the lock/unlock.  IWBN to have some kind of guard class that ensures they're always matched (ignore me if such a thing already exists).

ImageFrameGenerator and LazyDecoingPixelRef are making sure lock and unlock is balanced.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.