[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 #22 from Stephen White <senorblanco at chromium.org>  2013-01-17 21:53:28 PST ---
(From update of attachment 183223)
View in context: https://bugs.webkit.org/attachment.cgi?id=183223&action=review

>> Source/WebCore/platform/graphics/chromium/DiscardablePixelRef.cpp:65
>> +    return m_discardable;
> 
> Is it possible that after this is allocated that it is immediately discard before lock? I think allocateAndLock has to be one operation.

+1 to that.  Could this be done in the onLockPixels() somehow?

> Source/WebCore/platform/graphics/chromium/DiscardablePixelRef.cpp:73
> +    if (m_discardable)
> +        m_lockedMemory = m_discardable->lock();
> +    *ctable = m_colorTable;
> +    return m_lockedMemory;

This looks like it's the only place m_lockedMemory is assigned, and it'll return garbage if m_discardable is NULL.  Am I missing something?

>> Source/WebCore/platform/graphics/chromium/ImageDecodingStore.cpp:114
>> +    if (m_discardableMemoryEnabled && !(*cachedImage)->bitmap().pixelRef()) {
> 
> Is this correct? I think SkBitmap always has a pointer to SkPixelRef but SkBitmap::getPixels() can return 0 because lock on SkPixelRef failed.

SkBitmap can exist without a PixelRef (when the SkBitmap owns its own memory directly).  Not sure if that'll happen in this particular case, but it's definitely a supported semantic.

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