Introduce Layers in the Renderer

[CryZe]

There are a lot of elements that are basically almost entirely static on the layout. Other elements such as the timer are frequently changing. In the browser we already noticed that by pushing the timer onto its own layer, you get a fairly big performance boost out of it.

Here's that Pull Request:

LiveSplit/LiveSplitOne#378

We want to apply a similar idea to the native renderer. In order to do this we first introduce flags in the layout state that mark whether a component or a part of a component is at the specific time considered frequently changing. By doing this not only does the native renderer benefit from it, but other renderers such as the web version can also make decisions based on that, as opposed to only applying the optimization to the timer component.

With all the components providing these flags, the renderer can now split up the frame into a bottom layer and a top layer where all the frequently changing elements are rendered onto the top layer and all the other elements rendered onto the bottom layer. In fact the top layer is actually the frame buffer and it simply gets cleared by copying over regions from the bottom layer. That way there is no additional compositing necessary.

Additionally the renderer is now more of a scene manager that manages entities in a scene rather than directly emitting draw calls to a backend. The scene is a data structure that allows traversing the two layers in any way a renderer (i.e. what used to be a backend) would want to render them out. So the whole design is a lot more decoupled now.

[wooferzfg]

Should we also have something like this here? "Additionally a boolean is returned that indicates if the value is currently actively changing as time is being lost."

[CryZe]

Yeah that should've probably mentioned it. I'll try to sneak it into some future commit.

[wooferzfg]

What's the reasoning behind the calculations here? I guess I don't really understand where these numbers are coming from.

[CryZe]

Here we intend to rerender the top layer, for that we need to copy all the pixels from the bottom layer over so the top layer has a clean slate to work with. However not actually all the pixels need to be copied over, only those that the top layer actually intends to draw on top of (and somewhat from the previous frame, as the top layer might've moved, so we potentially need to replace some pixels where we now intend to not have anything in the top layer anymore). So we calculate a bounding box for the top layer and merge it with the previous frame's bounding box. I haven't benchmarked this, but I wanted it to be a single copy operation, so what I do instead is I copy consecutive image rows, so it can be a big memcpy of n pixels with n being a multiple of the image width. min_y and max_y get rounded down / up respectively here, so we don't miss any pixels as those y values are floating point. It might make sense for this to be a two dimensional loop instead where we also limit the copying on the x-axis. Not sure if the branching checking cost is higher than just bursting through and copying everything consecutively.