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

[bugzilla-daemon at webkit.org]

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





--- Comment #31 from Kwang Yul Seo <skyul at company100.net>  2012-07-18 16:12:56 PST ---
(In reply to comment #30)
> (In reply to comment #28)
> > (In reply to comment #26)
> > 
> > It seems RenderingLayerBacking is the only place where one of metadata friends is used to trigger parallel image decoding in the current code paths.
> > 
> > We've realized that we don't need to use parallel image decoding for these metadata friends.
> > 
> > So we will change our implementation to use parallel image decoders only when we need to paint images.
> 
> That makes sense. My observation of the code is that those metadata functions are supposed to return default values when a frame is not ready (being not downloaded) as of todays, so I think they probably don't need any handling.
> 
> If the starting point for parallel image decoding is just when painting a BitmapImage to GraphicsContext, I wonder if it will make the intention clearer something like:
> 
> drawImage(xxx, bool prepareImageAsynchronouslyIfPossible = false);
> 
> Under the hood GraphicsContext all your changes including ParallelImageDecoder remains the same. My point is this eliminates using a type (RetainedModeBitmapImage) to denote the desired behavior of image decoding caused by painting, instead have this built-in to the painting methods.
> 
> One other tiny performance benefit of this is when GraphicsContext detects the frame is not ready and skip painting an empty frame.
> 
> What do you think?

That depends on how we refactor RenderingLayerBacking. In this case, we retrieve a NativeImagePtr from RetainedModeBitmapImage. So we can't simply delegate the decision to GraphicsContext.

I will let you know once we decide how we refactor RenderLayerBacking.

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