KHTML developers: Animated GIF playing

[Mosfet]

On Tuesday 13 May 2003 08:39 am, Stephan Kulow wrote:
> On Tuesday 13 May 2003 14:57, Mosfet wrote:
> > Well, dithering shouldn't be a problem... GIF color tables can only have
> > 256 colors ;-) You can have a global color table and local ones, but each
> > image frame will use only one colormap with 256 colors. Here's what the
> > spec says:
>
> I'm afraid I don't understand your ascii art. But as a matter of fact you
> can have 100 frames on different positions of the background with different
> 256 colours and each having it's own local color map.
>

Not my ASCII art, it's the GIF spec's ;-) It shows the highest color index is 
255. 

But yes, your absolutely right - In animation you have a bunch of different 
sub-images with possibly their own local color tables at different offsets. 
For 256c displays Qt should handle this when converting from an image to a 
pixmap, but it would be more optimal to dither everything to the same palette 
to avoid strange color changes when showing different frame subimages. I 
didn't consider that.

> BTW: try to display http://www3.sympatico.ca/asid/in.gif, konqueror can't,
> xv can't, mozilla can, display can, IE can (afair), pixie can't. :)
>

Pixie can now ;-) Since Pixie views local images on your hard drive this is 
easy - I just use GIF slurping to load a local file.

The incremental loading is my big concern. dgif_lib.c, the libungif decoder, 
only reads local files but the calls to open and read a file are #define 
macros so it's easily reimplemented. It would be easy to stick something that 
can block and wait for data in there. I would still need to read the gif 
block by block, but this would give us a standard and more robust 
implementation I think, and it's only 1013 lines including comments...

BTW, I'm seeing on other threads people have responded to me without CC'ing 
me. Don't do this - I won't see it! >;-)

> Greetings, Stephan