A race condition in the animations manager can leave a dangling
timerEvent() callback firing at a high frequency (>120 FPS) in the
main loop even though there is no active animations.
An update of the animations manager returns directly when there is no
active animations. If there is at least one active animation, it stops
the timer and schedules a new update before updating animations.
Depending on the Integration implementation, the scheduling call can
be postponed after the current update. The actual postponed call
unconditionally schedules an update by starting the timer. The issue
is that in the meantime the last remaining animation could have been
removed and, when the timer callback would be fired, the update would
return directly (since there is no active animations) without being
able to stop.
The explanation above ignores the updateQueued() cases of the
postponed call for simplicity. These cases do not result in infinite
updates like the timer case but still imply one useless (invoked)
update.
This fix adds a condition in the postponed call ensuring there is at
least one active animation before processing.
telegramdesktop/tdesktop#3640telegramdesktop/tdesktop#4854telegramdesktop/tdesktop#5436
f783243e13