It makes sense that nobody noticed it given that it only happens for values
that are EXTREMELY close to 1.0, and you would really have to be looking
for this bug in order to find it. Anyway, good to know that this will no
longer be an issue!
On Mon, May 7, 2012 at 1:52 AM, Cedric BAIL
I noticed today that this function is broken at 1.0 (final frame) using
ECORE_POS_MAP_ACCELERATE; it doesn't return 1.0 as it should, and thus the
final frame is never reached. I've committed an amazingly hackish fix, but
feel free to modify it if there's a slower, more mathematically correct
More info, this algorithm is actually wrong altogether. With my recent
commit, the final position will be correctly returned as 1.0, but frames
just prior to it will be greater than 1.0, which is clearly wrong.
On Sun, May 6, 2012 at 12:44 PM, Michael Blumenkrantz
michael.blumenkra...@gmail.com
On Sun, 6 May 2012 12:50:27 + Michael Blumenkrantz
michael.blumenkra...@gmail.com said:
ummm... i suspect a bug in your code. that accelerate mode has been in edje for
years - ecore just copied the algorithm/code out into a shared func in edje.
i've had test code for it - here is the dump of
0.87 consistently returns a value greater than 1.0 when using
ECORE_POS_MAP_ACCELERATE.
On Sun, May 6, 2012 at 1:11 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Sun, 6 May 2012 12:50:27 + Michael Blumenkrantz
michael.blumenkra...@gmail.com said:
ummm... i suspect a bug in your
On Sun, May 6, 2012 at 10:34 PM, Michael Blumenkrantz
michael.blumenkra...@gmail.com wrote:
0.87 consistently returns a value greater than 1.0 when using
ECORE_POS_MAP_ACCELERATE.
On Sun, May 6, 2012 at 1:11 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Sun, 6 May 2012 12:50:27 +
