[Bug 24022] New: [GTK] GdkPixbuf based ImageSource and ImageDecoder

[bugzilla-daemon at webkit.org]

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

           Summary: [GTK] GdkPixbuf based ImageSource and ImageDecoder
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zuh at iki.fi


So since the intended way of loading images in a GTK+ environment is the
GdkPixbufLoader, we should look into using it as a image source in the GTK+
port.

This would allow us to tap in to the multitude of formats available (in a
fairly standard installation, there's 16 different loader plugins) with just
one decoder implementation.

That sounds a bit too convenient to be true, and so it is. There are major
obstacles in the way:

The internal representation of GdkPixbufs is not compatible with that of cairo
and WebCore (RGBA32Buffer), so a conversion needs to be done for the data. This
is not devastatingly slow AFAIK so it's not a fatal problem.

The API of GdkPixbufLoader is very abstract, specially the animation support.
While nice for the application developer that just wants to roll the animation,
this makes it very difficult to use GdkPixbufLoader as an intermediate library.

The static image loading is actually easy to achieve, the only snag there is
the conversion which forces the data to be copied from the pixbuf instead of
just stealing it.

The animations are a different thing though. The GdkPixbufAnimation API is
constructed so that you feed it a start time, request a frame and set a timer
to do it again after the duration of the frame. Easy as pie, but unfortunately
the time-based animation style is enforced so vigorously that there is no API
to query the number of frames at all, even for animations that have frames.

This doesn't sit well at all for the WebCore internals, it expects to get a
vector of frames with durations and looping information. After some pondering,
I got it roughly working with some "clever" hacks.

To decode all the frames, I feed a start time to the loader and when I get a
frame, I simply add the frame duration to the time and request another one. If
the duration is -1, I'll know it's the last frame and can stop there. Looping
animations however don't give that -1, they just rewind to the first frame
without the caller ever noticing. Except that you can, due to the backend
implementation and by being fiendishly cunning, keep the pixbuf pointer for the
first frame and compare the current one to that. When they match, you'll know
that the animation looped and can quit fetching the frames.

Needless to say, this is nothing that should be even considered to be relied on
for real, but the patch I'll attach should at least serve as a example of what
kind of API is needed in GdkPixbufLoader for this to become a real option.
There's upstream bug for enhancing the GdkPixbufLoader API at:

  http://bugzilla.gnome.org/show_bug.cgi?id=358109

For the mean time, we could use the GdkPixbuf decoder (without support for
animations) as a fallback for the formats that do not have decoders in WebKit.


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