API problem with the new GdkPixbufAnimation used with progressive loaders

[Helmethead <hoshem mel comcen com au>]

When you load a gif animation with a GdkPixbufLoader and try to display it progressively, the result is very unappealing because the iterator does not wait for the frames to finish loading and loops back to the start of the animation to display it again. Since the total time for the animation changes when a new frame is loaded, and the _advance function uses a modulus of this to calculate what frame to display, the frame that the iterator loops back to might not even 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...

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?

One solution is to just interpret them with some adjustments for the time spent loading the image. Problem with this is, there are two ways an application could calculate the GTimeVals it passes to _advance: using the _get_iter value as a reference or using the current time as a reference. For this to work we would have to specify one or the other method in the docs, which would make it more of a pain to use.

I can think of 3 ways to deal with this.

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?

If there is, then..

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.

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.

So.. I hope I've made sense, please comment :)