Strange bug with animation
We have an animation that decrease a number and we have no idea why it stops before the end on my machine but not the one of alexis.
To reproduce
Metacello new
baseline: 'CoypuIDE';
repository: 'github://pharo-graphics/CoypuIDE/';
onConflict: [ :ex | ex useIncoming ];
onUpgrade: [ :ex | ex useIncoming ];
load.
MfTimerElement exampleSimpleTimer
On my machine it produces
when I click a lot (6 times fast instead of one) I get
I have randomly similar behavior; With current code, the counter rarely goes down to 0. If I put a breakpoint into the loop, like
anim addEventHandler: (BlEventHandler
on: BlAnimationLoopDoneEvent
do: [ :e |
currentAngle := currentAngle - decreasingAngleStep.
self updateAnnulusAngle: currentAngle.
self updateValue.
self halt.
"self background: Color random" ]) ]] .
The counter never reach 0, but stop at 1, 2, 3 4, or higher.
I would suggest this code, which is really done for number transition:
initializeAnimation
| started |
anim := BlNumberTransition new
from: 0;
to: value;
by: 1;
duration: value seconds;
"onStepDo: is called on every space pulse. Color are updated at each pulse..."
onStepDo: [ :aValue :anElement |
| currentValue |
currentValue := value - aValue.
currentAngle := 360 - (decreasingAngleStep * aValue).
self updateAnnulusAngle: currentAngle.
self updateValue: currentValue.
"self background: Color random" ].
started := false.
self addEventHandlerOn: BlMouseDownEvent do: [ :a |
started ifFalse: [
started := true.
self addAnimation: anim ] ]
We got this too and it depends on the machine. I got this bug on my M2 but impossible to reproduce it on alexis' machine
I think I got it.
In original code:
initializeAnimation
| started |
anim := BlAnimation new
duration: 1 seconds;
loops: value.
started := false.
self addEventHandlerOn: BlMouseDownEvent do: [ :a |
started ifFalse: [
started := true.
anim addEventHandler: (BlEventHandler
on: BlAnimationLoopDoneEvent
do: [ :e |
currentAngle := currentAngle - decreasingAngleStep.
self updateAnnulusAngle: currentAngle.
self updateValue.
self background: Color random ]) ]] .
self addAnimation: anim
The animation is directly added to the element. When an animation is added, it's started immediatly. So if you click on the element just after opening, your counter will behave as expected. If you wait before clicking on it, It'll end before counting down, as it was already started. Because you didn't add the event handler 'BlAnimationLoopDoneEvent', the update is not happening graphically.
I have moved even handling outside of the BlMouseDownEvent, and added animation to the element when user click on it. It's now working. final code:
initializeAnimation
| started |
anim := BlAnimation new
duration: 1 seconds;
loops: value.
anim addEventHandler: (BlEventHandler
on: BlAnimationLoopDoneEvent
do: [ :e |
currentAngle := currentAngle - decreasingAngleStep.
self updateAnnulusAngle: currentAngle.
self updateValue.
self background: Color random ]).
started := false.
self addEventHandlerOn: BlMouseDownEvent do: [ :a |
started ifFalse: [
started := true.
self addAnimation: anim ] ]
I would still advise to use BlNumberTransition, as it better reflect the intent :-)
I guess, on your M2 machine, the animation was even faster to start, which may explain the discrepancy. But I cannot reproduce the -48 given in the 2nd screenshot.
@Ducasse I couldn't reproduce the bug on my Macbook Pro 2018 (intel)
I think the solution of @rvillemeur is correct, it's the Bloc user in this case who must take care of now adding the animation if another is currently running. Right?
A last version, using BlAnimation API, removing the need for started variable:
initializeAnimation
anim := BlAnimation new
duration: 1 seconds;
loops: value;
addEventHandler: (BlEventHandler
on: BlAnimationLoopDoneEvent
do: [ :e |
currentAngle := currentAngle - decreasingAngleStep.
self updateAnnulusAngle: currentAngle.
self updateValue.
self background: Color random ]).
self
addEventHandlerOn: BlMouseDownEvent
do: [ :a | anim isRunning ifFalse: [ self addAnimation: anim ] ]
@Ducasse do you consider @rvillemeur's code snippet closes this issue?
I do not know I should check on the timer code.
But this is really important to document this behavior. It should be added to the chapter on animations.
I'll add it to graphic book next week
Renaud
25 juil. 2024, 08:29 de @.***:
But this is really important to document this behavior. It should be added to the chapter on animations.
— Reply to this email directly, > view it on GitHub https://github.com/pharo-graphics/Bloc/issues/532#issuecomment-2249556701> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/ABXAC53LIJOEW4ABGJ37RODZOCLK5AVCNFSM6AAAAABJGNH5KGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBZGU2TMNZQGE> . You are receiving this because you were mentioned.> Message ID: > <pharo-graphics/Bloc/issues/532/2249556701> @> github> .> com>
Were you able to add it to the book @rvillemeur ?
@tinchodias , updated information on animation were added. You can have a look here: https://github.com/SquareBracketAssociates/Booklet-Graphics/blob/main/Chapters/bloc/animation.md. Let me know if you have any comment.
The documentation in general and about animation looks great. Thank you. So I close this issue.