[Webkit-unassigned] [Bug 90375] Parallel image decoders

[bugzilla-daemon at webkit.org]

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


Hin-Chung Lam <hclam at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hclam at google.com




--- Comment #25 from Hin-Chung Lam <hclam at google.com>  2012-07-17 21:17:58 PST ---
Thanks for sharing the patch.

As mentioned before we have the same goal to allow the notion of asynchronous image decoding. Under the hood it can be parallel image decoding like your patch does, or in the Chromium case we'll defer the image decoding for a later time. We have a common goal here.

I have some questions I would appreciate very much if you can help me understand better your patch.

If I understand your code correctly the use of RetainedModeBitmapImage is to detect drawing, metadata calls while image decoding can be done asynchronously, by using a counter and later call to ensureFrameIsCached(), requestFrameAtIndex() will try to parallel image decoding.

One part I have problem understanding is when is an image parallel decoded? toRetainedModeBitmapImageIfPossible() seems to be called only when an BitmapImage is painted to a GraphicsContext, yet method call to BitmapImage::frameDurationAtIndex() and other methods in BitmapImage also seems to trigger parallel image decoding.

Q1: Will BitmapImage::frameDurationAtIndex(), orientationAtIndex() and these metadata friends trigger parallel image decoding?
Q2: Are these code paths currently used? Or do you expect all parallel image to be triggered by drawing a BitmapImage into a GraphicsContext?

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