Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.8.0, 5.9.0
-
af521a8df6caec41f626a4b3319601c20adff711 (qt/qtdeclarative/dev) c2df9ce7b0cb6ac9a9117578a167d54a708c64b3 (qt/qtdeclarative/5.15)
Description
AnimatedSprite stops updating after it was (indirectly, effectively) hidden, even if it subsequently becomes visible.
The change in dtdeclarative@f5e2783, which fixed , has also caused a regression. Once AnimatedSprite stops updating due to its effectiveVisible becoming false (e.g. parent component being hidden), it then doesn't resume updating even after effectiveVisible becomes true (e.g. parent component becoming visible).QTBUG-55935
Cause/Analysis
As far as I understood the code, the animation "loop" is driven by a call to QQuickAnimatedSprite::update, which results in QQuickAnimatedSprite::updatePaintNode being called on the next update. QQuickAnimatedSprite::updatePaintNode in turn calls QQuickAnimatedSprite::update, starting the next iteration.
The above fix replaced most calls to QQuickAnimatedSprite::update with QQuickAnimatedSprite::maybeUpdate, which only dispatches to update if the item is effectiveVisible.
When effectiveVisible becomes false, the update/updatePaintNode "loop" stops. However, when later effectiveVisible becomes true, there is no provision to restart it.
Patch
I have a patch in hand (attached to this ticket) that observes changes to ItemVisibleHasChange, and restarts the update loop. The patch was developed for v5.8.0-derived code for our embedded platform, but the same fix applies cleanly to 5.9 and 5.10.
I am more than happy to rebase and submit a pull request, and would appreciate quick direction as to which branch this should go into.
Workaround
In case anyone finds this bug and wants a silly (but reliable) workaround, this code in your AnimatedSprite does the trick:
AnimatedSprite { ... onVisibleChanged: { // Workaround for a regression in f5e2783 (QTBUG-55935) // This restarts the update loop and resumes the animation if (visible) { paused = !paused; paused = !paused; } } }