Re: Deconstructing animations

[Matthias Clasen <maclas gmx de>]

Am Son, 2003-06-29 um 20.25 schrieb Havoc Pennington:
> On Sun, Jun 29, 2003 at 07:43:32PM +0200, Matthias Clasen wrote: 
> > No. All I want is a way to collect the sequence of pixbufs (and delays)
> > which I can get via a GdkPixbufAnimationIter, without running into
> > loops. I don't see how this would be giving up anything. Even mng
> > ultimatively results in a sequence of frames which are displayed one
> > after the other. 
> 
> Right, but it results in an infinite resolution series of frames. 
> i.e. I believe the format has things like "move sprite from point A to
> point B over N seconds"
> 

Well, GdkPixbufAnimationIter certainly doesn't give me "infinite
resolution". It's resolution is limited to 1frame/ms since the delay is 
reported as an integral number of milliseconds. Anyway, I think it would
be more useful to discuss the concrete api proposal I have made: lets
add

gint
gdk_animation_iter_get_loop (GdkPixbufAnimationIter *iter);

which would return how many complete loops the iter has already made
over the animation. You may object that one can conceive implementation
of GdkPixbufAnimation which produce an infinite number of frames without
ever repeating one...but in that case, it would be fine to just return 0
forever. Anybody harvesting frames from an animation would certainly be
sane enough to stop after having collected a few hours worth of frames
without coming to the end of the first loop...
 
> In future it'd be nice to support flash or svg also, with similar
> features.

Yes.

> It's probably fine to convert to frames by taking snapshots at some
> interval, but if you did 30fps for example that way, the resulting
> frame-based anim could be really huge. So perhaps the API should let
> you request a frame rate, or let you check whether the anim is
> frame-based?

One nice thing about the get_loop() proposal is that the harvester can
control the frame rate simply via the steps in which it advances the
iter.

Matthias