Update selected text area at the user's refresh rate

[thennothinghappened]

Describe the feature

I know this is a nitpick that your average sensible person wouldn't care about whatsoever, but, when editing code on a high refresh-rate monitor (i.e., considerably greater than 60hz), a code editor (or any text editor that permits selection) is generally expected to match this smoothness when using the mouse to select text.

This is the case for the default browser behaviour, and in others such as Monaco, and feels a bit jarring when Ace then doesn't do this, and uses a fixed update interval.

Use Case

This just feels a lot nicer! - and I'm sure that there's some others who use a high refresh rate monitor who'd appreciate it, but haven't been bothered enough by nearly enough it to ask.

Proposed Solution

I did some very basic digging, and found the line responsible here:

ace/src/mouse/mouse_handler.js

Line 185 in ef08dfb

var timerId = setInterval(onCaptureInterval, 20);

Here, setInterval is being used with a fixed update gap of 20 millis, which is the source of this slowness.

As a basic test I initially tried lowering this to 4, which drastically improved the result on my machine.
However, this is not necessary on a machine that isn't running at a higher refresh rate. Thus, I then also tried replacing the use of setInterval with requestAnimationFrame, and replacing timerId with a boolean timerShouldRun, which solved the issue.

I noted that Ace seems to have some kind of built-in fallback options for requestAnimationFrame on older browsers which may not support it, so I'd imagine this utility would be used in a proper implementation.

I also noticed that this magic number 20 is being used in quite a few places throughout the codebase - whilst some appeared to be for spacing out logic, I wonder if some other parts of editor functionality could be made a bit smoother by applying this same trick.

Another thing to note here is that most monitors are 60hz, in a standard setting. This comes to 16.666...ms per frame, which means that the use of 20 on most monitors is already going to be out of sync, thus resulting in a jittery look even on a standard monitor - I have a second monitor which is 60hz, and can confirm that by using requestAnimationFrame, it too feels noticably smoother, at least to me.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

ACE version used

1.37.4