KHTML developers: Animated GIF playing

Mosfet dan.duley at
Mon May 12 21:14:26 BST 2003

On Monday 12 May 2003 11:34 am, Dirk Mueller wrote:
> On Mon, 12 Mai 2003, Mosfet wrote:
> > I've been kindof annoyed at animated GIF playing using QMovie for some
> > time. It used to take a lot of resources, now it sometimes takes all the
> > CPU and makes the GUI crawl. Because of this I wrote my own animated GIF
> > player based on libungif. Qt's version manually parses each byte of the
> > GIF ;-)
> [KHTML developers listen under kfm-devel at btw]
> The actual problem is more KHTML related: often it repaints too much, and
> animated gifs trigger a repaint of the complete viewport and not just the
> tiny rectangle of the gif.

Eeek, that isn't good :/ Nonetheless the problems aren't just when used with 
KHTML. I had problems using just QMovie drawing to a widget that went away 
when I switched to a libungif version.

> I do wonder though if the libungif version would have less bugs than the Qt
> GIF reader (which is still terrible buggy).

Since you probably know more about KHTML than I do would you be interested in 
playing with it? There are a couple things that needs to be done:

First off, I have two small bits of code that I was playing with this weekend: 
One that loads a GIF, interlacing it if necessary. I did this first for a 
command-line thumbnail generation tool. The second bit of code loads a 
animated GIF and displays it in a widget, but doesn't do the interlacing. I'd 
have to add that, but that's *really* easy.

The second issue is handling incremental loading. Right now I load the entire 
GIF into libungif at once, (slurping). I'd have to switch this to reading a 
block at a time so it can incremental load off of KIO. This is more work but 
shouldn't be too hard. I already looked at some of the libgif utilities that 
process individual lines and have an idea of how I'd do it. BTW, I believe 
this is why Qt used it's own homegrown parser. I'd probably just read in an 
entire block at a time and process it so you'd get the image frames as they 
load but not the progressive drawing of each frame.

The approach I'd take is first I'd add interlacing to the animated GIF player 
that draws to a QWidget and give that to you to play with. I can separate it 
so you'd have a QObject that emits a signal like "updateFrame(const QPixmap 
&pix, int x, int y)" whenever you need to update, and a test widget to play 
with it. If you determine it's useful I'd then add incremental support since 
I don't need it for PixiePlus.

More information about the kde-core-devel mailing list