Ensure a minimum frequency for event processing even if the UI slows

Previously we relied just on requestAnimationFrame, which should stay
fairly proportional to UI rendering perf I think. Unfortunately though
this is paused completely in the background (not just throttled) and
could theoretically reduce processing to very slow low levels if
something else starves UI updates. To help with that, we now use a
setTimeout backup as well.

Author: pimterry

src/model/events/events-store.ts

@@ -195,6 +195,11 @@ export class EventsStore {
     private queueEventFlush() {
         if (!this.isFlushQueued) {
             this.isFlushQueued = true;
+
+            // We use both setTimeout _and_ requestAnimationFrame. This aims to
+            // ensure a minimum update frequency (even if throttled or the UI is slow)
+            // but provide a very fast update frequency the rest of the time.
+            setTimeout(this.flushQueuedUpdates, 500);
             requestAnimationFrame(this.flushQueuedUpdates);
         }
     }
@@ -212,11 +217,12 @@ export class EventsStore {
 
     @action.bound
     private flushQueuedUpdates() {
+        // N.b. this is called twice for each flush, but that's fine - very cheap to do so.
         this.isFlushQueued = false;
 
-        // We batch request updates until here. This runs in a mobx transaction and
-        // on request animation frame, so batches get larger and cheaper if
-        // the frame rate starts to drop.
+        // We batch request updates until here. This runs in a mobx transaction and on
+        // animation frame + slow setTimeout. The goal being that as rendering blocks
+        // for longer, batches will get larger and cheaper.
 
         if (this.eventQueue.length > LARGE_QUEUE_BATCH_SIZE) {
             // If there's a lot of events in the queue (only ever likely to happen