[Webkit-unassigned] [Bug 27561] ImageDecoder enhancements for WINCE port

[bugzilla-daemon at webkit.org]

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





--- Comment #36 from Peter Kasting <pkasting at google.com>  2009-08-14 11:42:26 PDT ---
(In reply to comment #35)
> Seems RGBA32Buffer will be modified to support more formats. Are you planning
> to do this?

I'm planning to remove the name "RGBA32" from the class, since that class
actually doesn't support any formats at all; the underlying native image types
do.  Though right now none of those native image types uses anything other than
32-bit ARGB (or RGBA, or whatever), they could, and my suspicion is that that
decision is best left to those classes.  I haven't coded it so I can't be sure,
of course, but I think rather than having things like is16Bit() and raw
bit-writing ops directly in this header, those should be pushed to places like
what you've written as SharedBuffer.

Being able to cleanly integrate ports like WinCE that desire lower-bitdepth
storage formats is a key motivator to doing this, so whatever solution we land
on certainly has to work for you guys.

> After that, you will find that JPEG doesn't have alpha channel, so
> it may use 24bit format or RGB565 to store decoded data.

It could; it's not clear without trying it whether that will be a big win for
backends like Skia and Cairo.  Backends that did this would also need to ensure
that their code doesn't rely on the image storage being 32-bit; I think Skia
might, at the moment.

> So even you hack frameHasAlphaAtIndex(), it won't work.

FWIW, at the moment Cairo uses frameHasAlphaAtIndex() to determine its
compositing op, but Skia just uses the real image data inside the SkBitmap, and
ignores this function entirely.  It might make sense to have that kind of
pattern everywhere, since I imagine most native image storage formats can tell
you if they use an alpha channel...

> Also, on some devices, alpha blending may be slow, or even not supported.

Having it not supported entirely would make a platform pretty unusable since
not only most of the image formats, but all kinds of other CSS, SVG, etc.
operations need alpha.  So I'm not as concerned with designing for that case. 
Slow is another story; we do probably want to make it possible for ports to
avoid alpha-blending where possible.  I wonder if we need ensureHeight() and
friends to do that, though; in the current RGBA32Buffer API, it would be pretty
simple to set the decoded height correctly on an underlying native image
without needing an explicit call from the decoder.  This is because the
decoders move monotonically through the rows of an image, and set the status to
FrameComplete when they finish.

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