Re: Interesting animation bug

2013-12-16 Thread Alex Harui
On 12/16/13 10:08 PM, "Justin Mclean" wrote: >Hi, > >> In one case start method is called right away, in the other only after >>the startDelay has passed. >But then I guess the question is when should start be called at time zero >or after start delay? IMO, start delay should delay the start of

Re: Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, > In one case start method is called right away, in the other only after the > startDelay has passed. But then I guess the question is when should start be called at time zero or after start delay? Justin

Re: Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, > Maybe worth further investigation? In one case start method is called right away, in the other only after the startDelay has passed. Looks like startDelay isn't passed down in the first case, before start being called it will return NaN. Not 100% sure but looks like there an error in Effe

Re: Interesting animation bug

2013-12-16 Thread Alex Harui
On 12/16/13 3:54 PM, "Justin Mclean" wrote: >Hi, > >> Do you know why Scale doesn't display NaN? >No. > >> I didn't see any code setting _playheadTime to zero, but I certainly >>could have missed it. >Not sure either. Maybe worth further investigation? > >> I think you're saying that since _pla

Re: Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, > Do you know why Scale doesn't display NaN? No. > I didn't see any code setting _playheadTime to zero, but I certainly could > have missed it. Not sure either. > I think you're saying that since _playheadTime is continuously increasing > even when waiting for startDelay, that there is no n

Re: Interesting animation bug

2013-12-16 Thread Alex Harui
Do you know why Scale doesn't display NaN? I didn't see any code setting _playheadTime to zero, but I certainly could have missed it. I think you're saying that since _playheadTime is continuously increasing even when waiting for startDelay, that there is no need to factor startDelay into the get

Re: Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, > In the bug, the user seems to want to see time increasing while time < > startDelay. More about having it consistent between the two types of animation, notice that both has a startDelay of 200 but return different values in that time interval. > Is that what you think should happen too, o

Re: Interesting animation bug

2013-12-16 Thread Alex Harui
In the bug, the user seems to want to see time increasing while time < startDelay. Is that what you think should happen too, or should it be 0 or NaN? If it should just increase, I don't understand the point of including startDelay. On 12/16/13 2:22 PM, "Justin Mclean" wrote: >Hi, > >> It is a

Re: Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, > It is a bit scary since the documentation took the time to mention that > playheadTime includes startDelay. Yes it should include the time from 0 up to and including startDelay, but it shouldn't be adding the full value of startDelay to it before it has happened. On a time line you have in

Re: Interesting animation bug

2013-12-16 Thread Alex Harui
It is a bit scary since the documentation took the time to mention that playheadTime includes startDelay. I don't know this code at all, but it makes me think that there is a reason for it. On 12/16/13 1:12 PM, "Justin Mclean" wrote: >Hi, > >> Why shouldn't playheadtime include the startdelay?

Re: Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, > Why shouldn't playheadtime include the startdelay? Because then the values returned are something like this: Elapsed Time/playheadTime 0/200 27/200 65/200 109/200 148/200 178/200 232/232 264/264 It also gives different results to anything that extends AnimateTransform (eg Scale), which w

Re: Interesting animation bug

2013-12-16 Thread Alex Harui
Why shouldn't playheadtime include the startdelay? -Alex On 12/16/13 3:55 AM, "Justin Mclean" wrote: >Hi, > >Here's a curious one: >https://issues.apache.org/jira/browse/FLEX-33974 > >From what I can see there's a couple of bugs in there. > >The most obvious one being: > public function get

Re: Interesting animation bug

2013-12-16 Thread Tom Chiverton
On 16/12/2013 11:55, Justin Mclean wrote: numRepeats += (_playheadTime - duration) / (duration + repeatDelay); See the original playheadTime above. Anyone see something I've missed or are the current tests possibly testing current incorrect behaviour? Well, this is an interesting one, because

RE: Interesting animation bug

2013-12-16 Thread Maurice Amsellem
Envoyé : lundi 16 décembre 2013 12:55 À : dev@flex.apache.org Objet : Interesting animation bug Hi, Here's a curious one: https://issues.apache.org/jira/browse/FLEX-33974 >From what I can see there's a couple of bugs in there. The most obvious one being: public function get

RE: Interesting animation bug

2013-12-16 Thread Maurice Amsellem
Ok thanks -Message d'origine- De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé : lundi 16 décembre 2013 13:12 À : dev@flex.apache.org Objet : Re: Interesting animation bug Hi, > Justin, I couldn't find the code you mention above. spark/effects/Animation.as

Re: Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, > Justin, I couldn't find the code you mention above. spark/effects/Animation.as in the spark project. Thanks, Justin

RE: Interesting animation bug

2013-12-16 Thread Maurice Amsellem
Justin, I couldn't find the code you mention above. In which class is it ? Maurice -Message d'origine- De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé : lundi 16 décembre 2013 12:55 À : dev@flex.apache.org Objet : Interesting animation bug Hi, Here's a cur

Interesting animation bug

2013-12-16 Thread Justin Mclean
Hi, Here's a curious one: https://issues.apache.org/jira/browse/FLEX-33974 From what I can see there's a couple of bugs in there. The most obvious one being: public function get playheadTime():Number { -return _playheadTime + startDelay; +return _playheadTime; } A