Re: [clutter] How are frame numbers handled in a timeline ?

On Thu, 31 Jan 2008 21:20:18 +0000, Emmanuele Bassi <ebassi_at_o-hand.com> wrote:
> for future reference, just open a bug in bugzilla: it's easier to attach
> patches and track the discussion for us. :-)

Yes, sorry for that, but working on clutter is a personnal project, but I'm doing this from my workplace as I don't have Internet access elsewhere, and I'm concerned about intellectual property problems (theorically, I'm not allowed to do this). So I didn't want to do too much fuss on this.

> On Thu, 2008-01-31 at 20:28 +0100, benoar wrote:
>
>> A timeline has a current_frame_num variable which tells the current
>> frame number. To me, it should be included in the interval
>> [0,n_frames-1], do you agree ?
>
> for "historical reasons", we defined the interval of a timeline to be
> [0, n_frames]. since both explicit animations and implicit animations
> depend on this interval, I think it's a bit too late to change it and
> expect everything to work. all the alpha functions, for instance, would
> have to be changed to take into account the new interval.

OK, I understand that the historical wieght may be too heavy. Even if one would say "it's never too late" ;-)

>> Because a lot of tests in clutter-timeline.c let this variable go to
>> n_frames. Most of the test are on "current_frame_num > n_frames",
>> which is wrong if you don't want current_frame_num to be equal to
>> n_frames.
>
> !(current_frame_num > n_frames) will evaluate as FALSE if the user or
> the timeline itself try to set the frame number to something that's
> bigger than the number of frames - which is pretty consistent with the
> interval as it has been defined (that is, [0, n_frames]).

OK, I realize this is concistent with how you think it.

>> It is strange that this kind of error has not be spotted earlier, so
>> maybe these particular tests were intentional. But the convention in C
>> is for the "indexes" to be from 0 to max_count-1, isn't it ?
>
> a timeline is not an array index, though. :-) every check you mentioned
> is consistent to the given range.

OK, so what is the "meaning" of the "current frame number" ?

I am just trying to find out what this means exactly, because I am building a clutter "toy" to try manipulating clutter objects, and look at what one can get when playing with them (I'm doing this in Python). As I want to display a progress bar for the timeline, I'd like to know from where to where the current frame number goes. And to me, when you say n_frames=10, you mean that you want 10 frames, not 11 ! (if current_frame_num goes from 0 to 10)

I spotted this bug as I thought the max frame # would be n_frames-1, and I got something over 100% when playing a timeline. But I didn't get it when the timeline loops !! This seemed to me very inconsistent.
By looking a bit closer to the code, I see that when a timeline hits the n_frames'th frame, thus looping, it immediatly rewind itself. As I was polling the timeline value on a periodic basis (I didn't use the "new frame" signal as it would be a bit heavy displaying every frame change at high FPS rate), I never saw a looping timeline hit n_frames.

Well, then, I wanted to add a rant to how this way of couting frames looks weird on clutter_ramp_func for example (think to the "if (current_frame_num > (n_frames / 2))" test when n_frames=4 and the timeline loops : you get 3 frames for the increasing part, and 1 for the decreasing one ...), but when I think to it, the way you do it looks a lot like current_frame_num=n_frames doesn't really exist, and it is quite concistent with my view of the [0,n_frames-1] interval. And for the clutter_ramp_func, the decreasing frame will be equal to the second incresing frame ("middle" value for the ramp), and the hypothetic n_frames' frame would be 0, which is the same result as frame 0. So this is consistent.

Sorry if this message is a bit confusing, but I was a bit confused when writing it, but now I understand better. One could say the when current_frame_num=n_frames, it's almost the same as being on frame 0. The only strange thing you get is that for an increasing ramp for example, if you loop, you will never hit n_frames, and so, never hit alpha's maximum. I don't know if it is a serious issue or not, but you may consider checking a bit further how the alpha functions reacts to this.

>> PS: I also spotted another bug, a double increment, line 782: it should
> be removed:
>> priv->current_frame_num += n_frames;
>
> yes, that's truly a typo. well spotted! I've just fixed it in SVN.

Thanks.

Cheers,
Benjamin

-- 
To unsubscribe send a mail to clutter+unsubscribe_at_o-hand.com