[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: loading GIFs
From:       Martin Jones <mjones () powerup ! com ! au>
Date:       1997-07-13 19:53:51
[Download RAW message or body]

Stephan Kulow wrote:
> 
> Hi guys!
> 
> After trying to implement animated GIFs, I've noticed a problem with
> this. If khtmlw finds an image tag, it asks kfm (kioslave?) to get
> this into the filesytem. After this is uses QPixmap:load and depends
> on the installed filters.
> The problem is, animated GIFs aren't a pixmap, they're many of them!
> For everybody not knowing that much about animated GIFS, I tell you
> something about it:
> 
> GIF89a is a stream format. It starts with the usual header and a
> (optional) global colormap. After that there are endless frames
> (usual is one :-), they are loaded til a sign ';'. So, it's really
> possible to create infinite GIFs, there isn't a number of them in
> the header. They come one after one. And I've seen such things in
> the web, but this would crash the mechanism of reading in the file-
> system. To be understood right: I don't mean the loops, animated GIFs
> do almost ever, this is an invention of Netscape and this you can see
> in an animated GIF as an block 'NETSCAPE2.0' :-), but this isn't de-
> fined in the GIF89 standard. A frame is optional a colormap, some
> information (below) and the normal datas, that are used in GIF87 too.
> That's the reason, why single GIFs are usual GIF87!
> The information for one frame is:
> 1. how long the gap after this frame is (in ms, but netscape uses
>  another factor for this, never messured exactly)
> 2. the offset (vertical and horizontal). You can define a animated
>  GIF (also a normal infact), that is 800x600, but has only data for
>  20x20.
> 3. of course, you can define interlace/non-interlace for every frame
>  separatly
> 4. what should happen, if the frame disappear. It can be cleared with
>  the background (usual the defined one in the GIF, but netscape uses
>  the one of the HTML page). It can be replaced by the frame before or
>  it can be not handled (that means, frame by frame)
> 
> Ok, hope you have a short overview about this topic. What we need is
> a structure, that describes the GIF. If it loops (how often, if), the
> size and the frames as QPixmaps with the informations.
> I've mailed Taj yesterday about this topic, since he is the expert
> for image filters, but didn't recieved an answer yet, so perhaps he
> don't know :-), but I'm hardly sure, that this can't be solved with
> QImageIO.
> The other problem is the mechanism with kioslave. Isn't it possible to
> create IPC to transfer the pics while they're loaded? Or even emiting
> signals, if some data arrived from the HTTP server. Correct my, if I'm
> wrong in this topic, I hadn't a hard look at kioslave. And related to
> this, I think, we must drop the mechanism with QImageIO, but I'm not
> sure about that, since I've read in the QT documentation, that QImageIO
> is ready for future extensions. I would volunteer to this async loading,
> since I've done such thing at the university with QT for a MM project,
> but I would like to discuss this first on this list, since this would
> change this some things in khtmlw.
> 
> Please let me know, if I'm totaly wrong here or if you have comments
> for this.
> 
> Greets, Stephan

My solution would be to create a KPixmap class again which has
support for animations, progressive loading etc.  I am also
unsure whether QImageIO can do what we want. I'm reluctant to
do too much work on this as it has been leaked that QT-1.3
includes support for animation.

-- 
bye,
Martin Jones
mjones@kde.org

[prev in list] [next in list] [prev in thread] [next in thread]