[Webkit-unassigned] [Bug 33268] make JPEG image dcoder read segmented SharedBuffer

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Yong Li <yong.li.webkit at gmail.com>  2010-01-06 15:02:13 PST ---
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > (From update of attachment 45993 [details] [details] [details])
> > > > +        Vector<unsigned char, 8192> buffer;
> > > 
> > > Is it a potential perf issue that we can decode at most 8K at a time?
> > 
> > A segment in SharedBuffer is 4k. in the case JPEG reader needs 2 segments to
> > continue moving, 8k is a good number. The vector can grow when 8k is not
> > enough. but I think 8k is better than 0 for performance (no need to call malloc
> > in most cases)
> 
> Oh, I meant in comparison to the pre-segmented-SharedBuffer case where we could
> perhaps decode the entire image in one shot.

in that case "buffer" is not used at all. also "segmenting" can be easy to be
disabled in SharedBuffer::append(). probably I should add #if ENABLE() there
> 
> > sometimes the low level decoding doesn't move on unless you feed it more data
> > in consecutive memory space. "buffer" is there for this purpose.
> 
> Yeah, I got the general idea that we were copying segments out to a contiguous
> buffer to then feed to the decoder.  I was trying to understand the details to
> double-check if there were any errors/edge cases/etc. but I kept getting lost
> in how many different offsets we were tracking.

life is not easy :) 

BTW, this algorithm has been running for a long while in iris browser winmob.
(I believe you've seen this in one of wince port patches)

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