Experiment with purely using Rust in the hot code

[CryZe]

React isn't all too well suited for hot code. It takes up the majority of our frame time, which is kind of sad considering the real calculations are happening in our Rust code. We could look into letting Rust manage the DOM for the layout renderer. For everything else we can still keep using React. This is also mostly just meant as an experiment to see how well this would work. There's various frameworks in Rust that basically replicate what React is doing for the most part such as yew, so it should be fairly easy to do a 1:1 translation. The major performance benefit here would be the ability to use a bump allocator for the VDOM and not serializing everything over to JS. The only communication with JS that ever needs to happen are actual changes to the DOM which are comparatively infrequent.

Here's a real world application that uses yew: https://caniuse.rs

The component code looks pretty similar to what we are doing with React: https://github.com/jplatte/caniuse.rs/blob/master/src/components/feature_entry.rs

[CryZe]

While working on the desktop version, there have been many improvements to the desktop renderer to the point where it can also work reasonably well with a canvas. So instead of letting the Rust code manage the DOM, we can just use the scene manager and let it manage a canvas instead. It's not fully ready yet as the browser doesn't give us access to any font data, so we'd need to let the canvas render the text itself instead of letting livesplit-core manage that. Supporting custom text engines is however already halfway implemented. This unfortunately means we lose some flexibility in how we lay out the glyphs, but it's not something we really have a lot of flexibility over in HTML either. One thing that Canvas apparently can't really do is font-variant-numeric: tabular-nums. So that's probably something we would lose. However this automatically handles #159, #46 and #576 (and maybe more), so not only is it a really nice performance improvement, but also gets us on par with the Desktop version in terms of features and also means we don't need to maintain any HTML or CSS anymore for the layout rendering, which simplifies everything as well.

[Hurricane996]

https://github.com/LiveSplit/LiveSplitOne/pull/666

[Hurricane996]

this is a very barebones start at software rendering. i havent touched the font stuff yet, and there's also the problem of the draggable layout. but it's a start

[CryZe]

Oh no, I'm sorry, but I already have a branch that directly uses the canvas's rendering rather than using the software renderer. I would actually be interested how the software renderer performs in comparison, but especially for fonts it's necessary to let the canvas render them directly (as you can't access the user's fonts in any way) so I'm thinking that directly using the canvas for everything should be the way to go.

[Hurricane996]

it took me like 10 minutes to throw together its all good. The canvas stuff still has the problem of having 2 seperate render systems to keep in sync, but that's less of a problem than the font issue.

[CryZe]

Oh you mean because of the dragging capabilities? Yeah I think we may just remove that feature then.

[Hurricane996]

The html renderer's performance concerns are less important in the layout editor since we can turn the refresh rate way down. nobody's editing their layout mid run (citation needed). The issue that still stands is the dual codebase. Ultimately removing the drag feature won't do much harm, as I'm sure it's very rarely used.