Slow larva drag in Chrome and Chromium-based web browsers
Dragging a larva along part of its track is subject to an accumulating lag that can easily be 1 second or more. This has been observed on all web browsers, but seems to affect Chromium-baed browsers more strongly.
As the lag depends on the web browser, the javascript frontend is to be blamed, and the issue could be (at least) partially addressed in larvatagger.js.
From the perspective of the Julia side, the javascript code runs asynchronously and techniques like Observables.async_latest
seem ineffective, as we cannot detect when rendering is complete in the browser tab, and consequently cannot wait until the browser tab is ready again.
We could introduce a cooldown after an update, and drop all new updates but the last one, during the cooldown. This approach could also replace the ObservationPolicies.PeriodicObservation
strategy. The first attempt made in this direction seems encouraging.
However, this raises the question of optimising the duration of the cooldown. Basically, dropping updates is not harmless. On a powerful-enough workstation with Firefox, we are better without dropping updates. If the Julia app cannot measure the performance of the web browser, we may only make this parameter a config option, and consequently have to introduce of a config file.
A similar lag can be observed when quickly moving back and forth the time slider, but is less impactful on the UX.