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

[bugzilla-daemon at webkit.org]

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





--- Comment #35 from Yong Li <yong.li at torchmobile.com>  2009-08-14 11:29:38 PDT ---
(In reply to comment #30)
> (In reply to comment #23)
> > Created an attachment (id=34772)
 --> (https://bugs.webkit.org/attachment.cgi?id=34772) [details] [details]
> > 1) ImageFrameSink
> 
> Here's a spattering of comments all over this patch, based on a quick glance.
> 
> I assume that your motive for resurrecting the "decoded height" variable is so
> that when you paint a SharedBitmap you can do an opaque blit of the valid
> height (and avoid the undecoded portion entirely) instead of doing a
> transparent blit of the entire frame size?  If so, I'm not necessarily opposed
> to resurrecting the height member, although no other ports do this and I wonder
> if it actually saves much time (it's only relevant while an image is
> half-decoded and being painted, and at that point the user isn't getting
> high-speed animation or similar anyway).  If it doesn't actually buy meaningful
> performance, then returning true for frameHasAlphaAtIndex() (either using the
> method it has now, which I think is fine, or pushing this into all the
> decoders, which I think is unnecessary code duplication for no benefit) seems
> like a simpler and better way.
> 

Seems RGBA32Buffer will be modified to support more formats. Are you planning
to do this? After that, you will find that JPEG doesn't have alpha channel, so
it may use 24bit format or RGB565 to store decoded data. So even you hack
frameHasAlphaAtIndex(), it won't work. Also, on some devices, alpha blending
may be slow, or even not supported.

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