-
-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Animations freeze in WPF under heavy load. #2588
Comments
Thanks a lot for you detailed analysis. This sound to me like the correct interpretation. I will look into it. It freezes the current animation but it does not freeze any following Navigations or animations, is that correct? |
That's correct - following navigations will run as normal (though those could then encounter the same bug). |
Mapsui Version
4.1.3
Mapsui Platform
WPF (though it probably can happen on other platforms depending on how similar the logic is.)
Device
Windows desktop, and Windows tablets.
Describe the bug
There is seemingly a bug where animations will freeze under high app loading.
We think there's a bug in the animation logic in how
Navigator.UpdateAnimations()
checks for when the panning or zoom limit is reached. This gets the desired viewport from the animation, usesNavigator.SetViewportWithLimit()
to apply the viewport with limiting, and then callsNavigator.ShouldAnimationsBeHaltedBecauseOfLimiting()
which checks if the current viewport was not updated because the panning/zoom limits were reached,However this can spuriously trigger if an animation step happens to result in no change to the viewport before applying the limits.
The timer used for the animation (
MapControl._invalidateTimer
) is aSystem.Threading.Timer
, which queues timer events on the thread pool at a fixed rate - so if a timer's not processed quickly enough (or if there's a lot of other work happening on the thread pool) there can be multiple outstanding timer events, and these queued events can run in parallel.The animation step works out what the current viewport should be given the number of ticks since the animation started. This means that if two animation steps happen to run back-to-back or in parallel, they can calculate the same required viewport. This would trigger the early stop behaviour described earlier.
To Reproduce
Steps to reproduce the behavior:
Navigator.ViewportChanged
event handler with an artificial delay:Map.Navigator.ViewportChanged += (s, e) => { Thread.sleep(50); };
Map.Navigator.ZoomIn(1000, Easing.Linear);
Expected behavior
The animations should complete without abruptly stopping.
The text was updated successfully, but these errors were encountered: