On Thu, 31 Jan 2008 21:20:18 +0000, Emmanuele Bassi <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
