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

[bugzilla-daemon at webkit.org]

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





--- Comment #39 from Yong Li <yong.li at torchmobile.com>  2009-08-14 12:17:03 PDT ---
(In reply to comment #38)
> (In reply to comment #37)
> > (In reply to comment #30)
> 
> But does anyone do that?  It doesn't look like it from this patch.  Why build
> factory functions unless you need them?

See first patch. We have ImageFrameSinkWince defined which holds a SharedBitmap
as the buffer provider.

> 
> I don't understand.  I know how GIF animation and frame disposal methods work. 
> The existing ports handle them correctly without using this mechanism.  Why
> doesn't the existing mechanism work for you, and how do you deal with not
> having the frame-clearing optimization for large GIFs?  I would think on a
> memory-constrained platform that'd be even more important than it is on
> desktops.

I've fixed many bugs on it, and our browser runs OK. Let me review this and get
back to you. I did that so long time ago :) 

> What subclasses?

ImageFrameSinkWince, if I am not wrong.

> 
> > > Having both setRGB16() and setRGBA() seems like a poor API for callers.  Why
> > > doesn't setRGBA() just write the data in 16-bit format if the bitmap is 16-bit?
> > 
> > they also have different inputs
> 
> This response is vague enough that I haven't learned anything.  What is the
> difference and why can't it be created at the SharedBuffer or ImageFrameSink
> level?

I'm lost now. I thought you mean why setRGB16 and setRGBA cannot share a same
function. If that was the question, I would say separate functions are
definitely better.

> 
> > > Why does getFrame() return 0 when the status is frameEmpty?  An empty frame is
> > > still a valid one.
> > 
> > why? Who likes to waste CPU time on empty frame?
> 
> What CPU is being wasted?  We don't blit anything with empty frames.

So why cannot it return 0?

> 
> > > The proper use of setCanFreeBuffer() is not obvious to me.
> > 
> > This nofities the buffer that decoder has finished writting to the buffer, so
> > the buffer can be released when it's under memory pressure.
> 
> Isn't this the same signal as setting the status to FrameComplete?

FrameComplete is just for a single frame. But GIF decoder may still want to
read a finished frame when it processes the next one. 

> 
> > The one that I'm most concerned is about GIF m_compositedWithPreviousFrame
> > thing. That's complicated, and ImageFrameSink code works in a little different
> > way. Want to talk to somebody on this.
> 
> Maybe you could write up a short doc with descriptions of the existing code and
> your code, pointing out the differences and why they are valuable?

ok. but for why they are valuable, I have mentioned in bug 26467, see comment
#5

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