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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jul 19 01:30:33 PDT 2012


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





--- Comment #33 from Kwang Yul Seo <skyul at company100.net>  2012-07-19 01:30:31 PST ---
(In reply to comment #32)
> ah! That's right I forgot RenderLayerBacking. RenderLayerBacking does present an interesting case. In your code I understand now these two operations does actually trigger parallel decoding:
> 
> RetainedModeBitmapImage::currentFrameIsComplete() and
> RetainedModeBitmapImage::nativeImageForCurrentFrame()
> 
> Without this extra type calling nativeImageForCurrentFrame() would cause a synchronous decoding for RenderLayerBacking.
> 
> Just a thought here, actually adding the notion of asynchronous decoding to BitmapImage, e.g.
> 
> BitmapImage::prepareCurrentFrameAsynchronouslyIfPossible()
> BitmapImage::nativeImageForCurrentFrame(); // returns 0 if async frame requested but not ready
> BitmapImage::currentFrameIsComplete(); // just a getter to see if current frame is ready
> 
> prepareCurrentFrameAsynchronouslyIfPossible() is similar to your retained mode counter but have it built-in to BitmapImage.

Thanks. Your idea sounds good. However, it seems we have a few problems.

In addition to the methods you mentioned, currently the following metadata query methods of BitmapImage trigger (parallel) image decoding:

float frameDurationAtIndex(size_t);
bool frameHasAlphaAtIndex(size_t);
bool frameIsCompleteAtIndex(size_t);
ImageOrientation orientationAtIndex(size_t) const;

If you call one of these methods without wrapping the bitmap with RetainedModeBitmapImage, it cancels on-going parallel image decoding and start decoding again serially. If a client wants to use parallel image decoding, it must use these metadata methods very carefully.


We do want only NativeImagePtr createFrameAtIndex(size_t) to trigger image decoding, so we checked if it is possible to get the metadata without full decoding as we do with isSizeAvailable.

1) float frameDurationAtIndex(size_t)
This is available only when GIF decoding is done. We can't get the duration simply parsing the header as in the case of size.

2) bool frameIsCompleteAtIndex(size_t)
This represents the current status of image decoding. (I am not sure if we can call this as metadata.) If we return this without decoding, it can return false even when allDataReceived == true.

3) ImageOrientation orientationAtIndex(size_t) const
ImageSource always returns DefaultImageOrientation. So this is available before decoding.

4) bool frameHasAlphaAtIndex(size_t)
This is most difficult to know before decoding. We need to decode at least one row. As ImageDecoder::isSizeAvaliable() just decodes the header and lets us know the size, we can add ImageDecoder::frameHasAlphaAtIndex(size_t) and decode one row. However, this is still problematic.

ImageSource unconditionally sets alpha to true before decoding as in the following:

bool ImageSource::frameHasAlphaAtIndex(ImageFrame* buffer)
{
    // When a frame has not finished decoding, always mark it as having alpha.
    // Ports that check the result of this function to determine their
    // compositing op need this in order to not draw the undecoded portion as
    // black.
    // TODO: Perhaps we should ensure that each individual decoder returns true
    // in this case.
    return !frameIsCompleteAtIndex(buffer) || buffer->hasAlpha();
}

If ImageSource::frameHasAlphaAtIndex(size_t) does not trigger full image decoding, frameHasAlphaAtIndex can't know if decoding is complete or not. If GraphicsContext3D uses BitmapImage as in the following, it is problematic.

Assumption: allDataReceived == true.

bool hasAlpha = image->currentFrameHasAlpha(); // <- may return true.
// do something with hasAlpha.
image->nativeImagePtr(); // <- image's actual alpha can be false.



As you suggested, we can implement these metadata friends as simple getters which do not trigger image decoding, but then we must be very careful in using these getters.

That's the reason why we introduced RetainedModeBitmapImage class. If a client wants to use BitmapImage asynchronously, we can simply wrap it with RetainedModeBitmapImage and everything is taken care of. We know this is not the best solution, but we couldn't find a better solution.

Do you have any idea on how we can make these metadata queries simple getters?

-- 
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