[Webkit-unassigned] [Bug 108690] Add ImageFrameCache to facilitate access to ImageFrames

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 13 18:26:31 PST 2013


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





--- Comment #15 from Min Qin <qinmin at chromium.org>  2013-02-13 18:28:46 PST ---
To support animated gif and the capability to discard partially decoded images for deferred image decoding, we want calls to lock all the frames before we start decoding, and unlock them after decoder completes.
So we want a chromium specific lock()/unlock() calls for ImageFrame vector. Having a separate class makes us easier to do this platform specific change. Maybe I should add empty lock() and unlock() calls to USE(SKIA) to make this change more clear?

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > The idea is to isolate the platform specific bits into this ImageFrameCache class.
> > > 
> > > Right now it has allocator, it will be extended to have lock and unlock such that we can use discardable memory to back it. The concept is ImageDecoder is generic while ImageFrameCache and ImageFrame contain platform specific details.
> > 
> > I don't really see much advantage to USE(SKIA) in a new nested class vs USE(SKIA) in the ImageDecoder base class.  Unless you plan to put the platform-specific bits into an ImageDecoderSkia.cpp a la GraphicsContext[Skia].cpp?
> 
> I see now there is already an ImageDecoderSkia.cpp.  This is probably proof that I should not be reviewing this code.  :)
> 
> > Perhaps you could describe this design a bit further, since it doesn't appear in this patch.  I find it difficult to review code I don't see.  :)

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



More information about the webkit-unassigned mailing list