[Webkit-unassigned] [Bug 26467] Cross-platform image system architecture cleanup metabug

[bugzilla-daemon at webkit.org]

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





------- Comment #10 from yong.li at torchmobile.com  2009-06-17 11:29 PDT -------
(In reply to comment #9)
> (In reply to comment #5)
> > 3. We only support 16bit in 2 formats: RGB555 and RGB565, but it's 
> > determined by a macro switch. Images with alpha channel cannot use 16bit 
> > currently. Transparent GIF images with single transparent colors can also 
> > use 16bit if the transparent color doesn't conflict with other colors in the 
> > image after converting to 16bit.
> 
> I suspect if we implemented this for all platforms we might want a runtime
> switch instead of a macro.
>

Making it runtime can allow us to choose the format that is most suitable on
the target device at run time. But I'm afraid that could affect performance,
unless we take care of all pixel walking code like this:
case format A:
   for each pixels {
   }
case format B:
   for each pixels {
  }
...


>
> I think this is orthogonal to the idea of storing paletted (8bpp) data in the
> buffer but if it's not that's another design consideration here.
> 
> > 5. We also support scaling huge images down to smaller size, and this is 
> > done on the fly of decoding, so there's no extra buffer-to-buffer scaling. 
> > Refer to ImageDecoder.h and ImageDecocer.cpp in our GIT repository. This 
> > feature is available when USE(IMAGEFRAMESINK) is true.
> 
> This one might be a macro when implemented for everyone.  A port like Chromium
> would probably never want this, while a mobile port might always want this (?).
> 
> > 6. We also did some work for resource caching. We've implemented 
> > SharedBuffer in our way, and so that the buffer doesn't need to be flat 
> > Vector. Instead, it can be a series of segments. See the definition of 
> > OptimizedBuffer. And we make all image decoders (and other modules that uses 
> > text decoders) work with segmented source. This is currently only for WINCE 
> > & TORCHMOBILE. But we think it can be helpful for other platform, too.
> 
> This is the most confusing bit to me.  There's already an image cache in WebKit
> that can hang onto or discard decoded image data.  And there's also code that
> throws away the unneeded decoded data from large animated GIFs.  Is this work
> you've done separate from that, or integrated with it?  I worry about having
> multiple isolated caching systems as a single system seems like it would make
> better decisions.  I will have to look at precisely how you've implemented
> this.
> 
SharedBuffer is used for raw resource data (encoded data). The reason why we
allow segmented buffer is that memory situation on mobile device is very bad,
and allocating a big block of memory can fail. Also, it takes CPU time to
resize the Vector. I guess JSC::SegmentedVector is a good utility class for
implementing OptimizedBuffer easily.


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