Reworking the runtime

[davesmith00000]

This PR may not survive, I'm just using it so it's easier for me to check my own work.

So far I've done some refactoring. No suggestion that this is an improvement, but the exercise has helped me reacquaint myself with what's going on.

The idea is to do the following, from the issue comment:

In this model you render on requestAnimationFrame, as long as you saw a message in the last, say, ~2 seconds. So if your app is idle, the rendering will go idle, but while stuff is happening (whether triggered by the user or anything else) the rendering continues.

Rough plan of attack:

Step 1 - Update pokes the renderer:

• Remove ModelHolder
• A model update triggers redraw
• Redraw is on a Renderer class and returns a new instance (to be stored in a Ref?)
• Render has a finite state machine: Idle, Running
• When a redraw happens you record a timestamp, update the state to running (always, for now), then immediately render

Step 2 - Render runs on a loop (again):

• Instead of the update poking the renderer and a render being triggered, it instead checks: if running do nothing, if not running, start render loop and set state to running
• Render loop checks if < 2 seconds since last update, if true, loop, else state to idle and don't loop.

Something like that.

[davesmith00000]

After going round and round trying to do this with CE, I decided just to PoC it imperatively to see if it was going to work at all. It kinda does.

My CPU has always seemed a little more eager than others have reported, so I wouldn't worry that the number seems to jump quite high in the gif, or that it's a little twitchy. This is similar behaviour to what I see on this machine from Elm apps.

Will need to verify on other machines.

<gif removed as I've noticed a bug> :facepalm:

Also, this is fast linked, not full linked.

[davesmith00000]

Here you can see where the frame animations kick in when activity occurs, and drops off when the user stops doing work.

[davesmith00000]

Screenshot from the Cats Effect version, which has replaced the imperative implementation.

[davesmith00000]

If you have any free time to take a look at this @armanbilge, that would be great (don't worry if not :smile:). This appears to do the trick but probably doesn't do it the nicest way.

[davesmith00000]

From my testing, this appears to be a vast improvement on pages that are idle between user interactions. I can't tell if there's any real impact on pages that do constant work - like games.

We don't have a way of defining "options" for Tyrian yet (like Indigo's GameConfig), but I'm wondering if it would be beneficial to be able to switch modes when you know what kind of site you've got. The "low consumption when idle" mode developed here could be a default.

[hobnob]

This looks like it'll work in a vast majority of cases - as you say, I'm not sure about games, where the model might be updated a fair bit. That said - I think we should put it live as is, as I suspect most people will be using Tyrian for static sites, and Indigo for games. In my experience, even if you use Indigo for games and Tyrian as the UI, the actual amount of time you spend updating Tyrian's model is far far less than Indigo