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

List:       kfm-devel
Subject:    Re: loading GIFs
From:       weis () stud ! uni-frankfurt ! de
Date:       1997-07-14 2:26:44
[Download RAW message or body]

Hi,

Progressive loading of images is a fine thing.

The best would be the following:
KHTMLW gets a call whenever new image data has arrived.
KHTMLW does not care about where the data came from.

It tells as usual only that it needs some image data.

Since the other Stefan ( or Stephan, I am a bit confused, sorry )
makes a total rewrite of KFMs IO System - we might perhaps get
a stand alone IO System in some week,months whatever - we can
implement such nice things. An app using KFMlib will receive
a signal whenever new data arrived. You can then load the new
data from the same file, the IO system is writing to, or
we can transfer the data using IPC directly.

But this might take a while. Nevertheless one can implement
progresive loading of pictures. It might just take a while
until we can use this cool feature.

Bye
Torben


On Sat, 12 Jul 1997, 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
> 
> 

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