[Webkit-unassigned] [Bug 26379] Reconsider image decoding architecture/APIs

[bugzilla-daemon at webkit.org]

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





------- Comment #30 from bfulgham at webkit.org  2009-06-14 22:41 PDT -------
(In reply to comment #17)
> Now, since I read Holger's main concern as the existence of #ifdefs in
> ImageDecoder.h, I think there are ways to avoid them.  I'm thinking of pulling
> RGBA32Buffer out into a separate header that can live in graphics/ instead of
> image-decoders/, which I hope would make Holger a bit more comfortable.  Given
> the little I have heard about ImageBuffer, I think its goals are probably
> similar enough to RGBA32Buffer that the two can be combined into a single class
> that represents a single native frame with per-pixel write access.  An Image
> can then be one or more of these frames and an ImageDecoder can write into an
> image or its frame(s).  The exact details will take some care to avoid memory
> corruption; over the lifetime of the Chromium port we've managed to subtlely
> break image memory management several times, because it's quite tricky to get
> right.  I will also need to better understand the image caching system.

This seems reasonable to me.  After looking things over, the stuff in
ImageDecoder (RGBA32Buffer) that is duplicated in wx and Cairo are themselves
duplicates of concepts in the ImageBuffer class.

To build on some of Holger's suggestions, could the RGBA32Buffer be handled as
a cross-platform base class (which the ImageBuffer would inherit from), and
push the platform-specific logic into the individual ImageBuffer classes?  The
decoder class could then deal in ImageBuffers:

RGBA32Buffer::clear <==> ImageBuffer::clearImage
RGBA32Buffer::width/height <==> ImageBuffer::size

ImageBuffer would inherit some pixel-level access methods, which might or might
not be useful/good.

> [...] but I certainly like Holger's idea of collapsing all the separate implementaions into one for
> starters.

Agreed.


-- 
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.