Bug 24022 – [GTK] GdkPixbuf based ImageSource and ImageDecoder

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Kalle Vahlman]

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.

[Kalle Vahlman]

Created attachment 27781 [details]
A food-for-thought patch to add GdkPixbufLoader based ImageSource and ImageDecoder

[Martin Robinson]

It seems that after all this time, this is not something we really need. :/ The fact that we have shared image decoders/encoders is nice because it means that we have to maintain less code ourselves and we can maintain consistency with the other WebKit ports. I'll close this and we can reexamine it later if there is a high demand.