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

[bugzilla-daemon at webkit.org]

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


pkasting at google.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kevino at theolliviers.com




------- Comment #17 from pkasting at google.com  2009-06-14 14:14 PDT -------
(Adding Kevin Ollivier since he might have perspective on the wx side of
things.)

Thanks for the comments, Brent.  For background, a chief reason to go the
direction I have so far with RGBA32Buffer is to allow platforms to write
directly into a native buffer that they can then avoid copying.  If you
consider a single 1024 x 768 JPEG, storing the data in a Vector<unsigned> and
then copying it to a native storage location costs 3 MB and the cpu time to
copy.  Animated GIFs can be far worse than this since they have many frames,
although the decoders go to some effort to scavenge memory for large GIFs.  And
finally pages can have many images.  If you start paying 1 - 100 MB of extra
memory, plus the time to memcpy it, on a page, you will quickly understand why
the current design is useful.  And for backends that don't want to take the
time to use this model yet, it still accommodates the Vector<unsigned>
implementation quite well.

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.

I don't know whether ImageSource in its current state has much utility or
should be folded into another class, but I certainly like Holger's idea of
collapsing all the separate implementaions into one for starters.  Another
piece of work I know needs to be done is to make the BMP decoder decode on
demand rather than when setData() is called; I wrote that decoder a couple
years ago before I fully understood the ImageDecoder class, so it works but can
waste CPU/memory.  Luckily BMP and ICO are not too common on the web so this
doesn't turn out to be a huge headache.

I hope the suggestions above not only provide concrete ideas to move forward
but go at least some way towards satisfying Holger's concerns.  While I don't
think his patches on this bug are valid, I do think we can avoid #ifdefs in
ImageDecoder if that's a real sticking point for any ports.  In the meantime,
please let me know if the current system actively hinders any ports; comment 3
seems to imply that it is a problem for a number of people but I haven't heard
specific feedback from any of them.  By contrast, the GTK and wx folks were
very helpful last night on IRC in pointing out exactly what was and wasn't
working, so I was able to work with them.


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