Possibility to hang the app when adjusting the animation timing
rboller opened this issue · 4 comments
Describe the bug
When adjusting the animation start time AND a fine-grained increment is set (e.g. 10 minutes), it's possible to hang the app by setting the time range to be very large. This can be relatively easily to accidentally do if you're adjusting the start date year and "roll over" to 1948.
To Reproduce
Steps to reproduce the behavior:
- Load a geostationary layer
- Open the animation panel
- Set the increment to 10 minutes
- Click the "up arrow" on the start date year to roll over to 1948 (or change the start date to be sufficiently large)
This link will take you straight to the problem. The app will eventually catch its breath but is quite unhappy about the situation.
Expected behavior
Given that it would be impractical (to say the least) of creating an animation with millions of time steps, we should probably prevent the user from trying to do this (and from crashing the app in process).
This could possibly be addressed by limiting the number of allowed animation steps (which I think we should do anyway) but also, could be addressed by not having the date rollover to 1948. I think if you try to increase the year on the start date and it can't be increased, nothing should happen rather than the rollover. Or perhaps even the up arrow could be disabled in these cases.
I'll try out different maxframes for animations similar to GIF. The core issue is the util.snapToIntervalDelta function gets bogged down traversing through large ranges of 10 minute intervals.
I was already planning to limit the animation steps in the work on #3473 so we could just roll this ticket into that one essentially? Or if you want to address it in some other way here I'd say go for it.
Moved to WV-1948