Feedback requested - url rate limit function

[chrisj]

deployment - https://neuroglancer--pr975-g10oyxt3.web.app

This branch is set up to get user feedback on a proposed rate limiting function based on the size of the state (based on string length)

The value returned is in ms so using the default rate limit function f(x) = x, a string 1000 characters long will update at most once per second (less if there is no state change).

Currently the implementation only the following update interval when the state size changes. If the user changes the rate limit function, it issues an immediate state update and then immediately the new rate limit. This could be changed so that state changes could extend or decrease the current active interval.

In addition to the rate limit function, Neuroglancer will also update the state when you move your mouse to click in the address bar or if you press the default keybind to select the url (ctrl+L / cmd+L). The point of this is to update the url whenever you try to copy it from the address bar. Unfortunately those were the only reliable ways to trigger an update in time. If a user changes the keybind for selecting the url, this code won't react to that.

The rate limit function can be changed in the user settings. This is only there for gathering feedback.

Below that is an additional option "Save state before refresh" This is disabled by default, it ensures the state is saved before performing a refresh. Both this and the attempt to update before manually copying the url from the address bar are designed to be useful for very large states where the update rate needs to be high to prevent issues with the chrome browser.

In order to analyze performance of the rate limit function, there is a status bar message at the bottom that will appear every time a url is updated

There is also a debug message in the bottom right containing information about the current rate limit value in seconds, size of the state, and the rate limit function:

URL rate: 0.2 s (state size (x)=221, f=x)

[seankmartin]

This is pretty cool! I tried it on an example I have with 1300 layers, that always crashed with the old regular updates system. With linear growth based on the size of the state string it helped. I get the sense some kind of linear growth could be a starting point and if we get some feeling of a rough state size (I don't know, maybe 200k in size? My example is about 1mil in size) at which the update barely works we could add some kind of exponential growth past a certain size to effectively start to disable any time based updates, like

max(200, x + PENALTY * max(0, e ^ ((x - STATES_TOO_LARGE_THRESHOLD) / EXP_RATE_CONTROL)))

But overall with the extra handlers to try update the state when needed this generally feels good. The update on refresh seems reasonable to me to be on also