Zoom out crash?
Opened this issue · 3 comments
If the user zooms out too quickly way too many requests are made, and it becomes too slow. So limit the rate of scroll events somehow
There was always a bit of a trade-off between interactivity and performance and I never gave this part much attention, mostly because it's trickier than it seems. Limiting the events too much means that the interaction becomes less intuitive, we really want to keep the response fast in the most common case of looking quite closely at data.
It might make sense to use the current time window to calculate a suitable rate, but that will depend very much on the frequency of points in the data. Maybe the total number of points in the plot could be a clue. We could also take into account how long the last request took, and limit the number of requests per time according to that, but the caching in the back-end makes this kind of useless.
I considered disabling the scroll wheel entirely, but IMHO that's one of the nicest things about the user interface, and means that we need to invent another way to zoom in and out. I also considered limiting the max zoom out to e.g. a year (not really a solution but part of it) but you know someone will run into that :)
Anyway, I think this is pretty much as far as I got thinking about this, perhaps a simple "debounce" algorithm would be a good enough start.
Another related problem is that I never found a way to completely cancel a cassandra request once it has been made. This is annoying because if a user zooms quickly there could be several requests that are processed simultaneously, and eventually all are discarded except the last one. It might be possible to limit each client session to one request at a time, to prevent this.
The queueing can also be done on the client.
For example, when you ask for new images you are only allowed to have one 'running' request and one 'upcoming' request. When the first scroll event triggers you start one request for a new image, which turns into the 'running' request. When the next scroll event triggers and there's a 'running' request, save it as the 'upcoming' request instead. When more scroll events trigger, overwrite the 'upcoming' request variable and you will get the latest user interaction's request when the first request is done.
@doctordesh That sounds like a good solution that should be easy to implement!