Re: API problem with the new GdkPixbufAnimation used with progressive loaders

[Helmethead <hoshem mel comcen com au>]

On Fri, Jun 08, 2001 at 12:36:49AM -0400, Havoc Pennington wrote:
> 
> Helmethead <hoshem mel comcen com au> writes:
> > be the first frame. For example, when I try and progressively load
> > an animation, the iterator happily marches through it and the frames
> > display in an order something like this:
> > 
> > 1, part of 2, 1, 2, part of 3, 2, 3, part of 4, 2, 3, 4, 5, 1, 2, 3, 4, 5...
> > 
> 
> This is a feature. There are two things happening:
> 
>  1) progressive display - it keeps showing as much anim as it has.
>     Netscape does this as well. I don't know if it's good or not, 
>     but was copying web browsers here.

I just tested this with netscape 4.77 and it did this:

progressively load and display frame 1, wait for 2 to complete, display 2, wait for 3 to complete, display 3, etc. until the anim was finished and then it restarted and displayed the frames with normal delays. My proposal is this except progressively display all frames not just the first one.

Couldn't get mozilla 0.9 to load it (grr)

I don't think there's any reason this should not be done with MNGs.

> > Ideally IMHO, the iterator should sit on it's butt (return -1 to
> > delay_time calls until the frame is finished loading) and wait for
> > every frame in turn to be loaded before it starts to actually
> > iterate through the animation. Anyone has other ideas I'd like to
> > hear them :). The API problem here is that after this happens how do
> > you interpret time values passed to _get_iter and _advance?
> 
> If you're going to display nothing until you're fully loaded, then
> just don't display anything until you're fully loaded. Right?

Not displaying nothing, but displaying the currently loading frame progressively, and not changing frames until it's finished.

> > 1. Declare that using GTimeVals with GdkPixbufLoaders is stupid, and
> > that NULL should always be passed as the second argument to
> > _get_iter and _advance, when the animation is being progressively
> > loaded. But is there a case when it's useful?
> 
> You would pass non-NULL if you wanted to do something like play the
> anim at double speed. The times are arbitrary values, except that you
> can't go backward (because it isn't necessarily possible to go
> backward with e.g. MNG). So you could make the animation think time is
> moving at a different rate.

fair enough.

> > 2. Make the GTimeVals relative instead of absolute. The "time
> > already elapsed" is passed to _get_iter, and the "time elapsed since
> > last advance" is passed to _advance.
>
> I don't understand this I don't think.
> 

If an application author wants to start the animation 0.5 seconds from the start, and play at double speed, he'd do this (g_timeout_add complications removed):

GTimeVal gtv = {0, 500000};
iter = gdk_pixbuf_animation_get_iter (anim, &gtv);

while (1) {
result = gdk_pixbuf_animation_iter_get_delay_time (iter);
usleep (result * 1000 / 2);

gtv.usec = result * 1000;
gdk_pixbuf_animation_iter_advance (iter, &gtv);
}

This way, if the iterator has waited for the animation to load up, it can properly do what the app wants. It probably makes things easier on the app programmers too. I think this is the best option.

> > 3. Change the arguments to "starting frame" for _get_iter and
> > "no. of frames to advance" for _advance, where each frame is defined
> > as being separated by a call to _advance.
> > 
> 
> The issues are a) it can't drop frames for you then and b) MNGs don't
> have to have frames at all.

My purpose in defining "frame" was to say it applies MNGs too, a frame ends and a new one starts at the point gdk_pixbuf_animation_iter_advance() needs to be called :) but yes, this screws frame skipping. Scrap that.