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

[Havoc Pennington <hp redhat com>]

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.
 2) frame-dropping. the display is time-based, it isn't guaranteed to 
    show all frames, rather it keeps frames on schedule. The purpose
    of this is to keep the animation smooth. If you have a low frame 
    rate, then there should be no problem keeping up and frames will
    rarely be dropped, if you have a high frame rate then frames can 
    get dropped to maintain the proper timing of the animation.

Note that the only future anim format we're likely to support is MNG,
which is not frame-based but rather time-based, so the API is done
with that in mind. e.g. an MNG might say "move this sprite at velocity
X over the following distance"

> 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?

i.e. don't display the image until you get the "closed" signal. If you
want you can just display the result of gdk_pixbuf_loader_get_pixbuf()
until the loader is closed.

I'm pretty sure this does what you want.
 
> 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.

> 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.

> 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.

Havoc