Skip to content

Improve Paint Times#378

Merged
CryZe merged 1 commit intoLiveSplit:masterfrom
CryZe:reduce-paint-time
Jun 6, 2020
Merged

Improve Paint Times#378
CryZe merged 1 commit intoLiveSplit:masterfrom
CryZe:reduce-paint-time

Conversation

@CryZe
Copy link
Copy Markdown
Collaborator

@CryZe CryZe commented Jun 6, 2020

In most frames only the timer will be redrawn. By moving it into its own browser layer, we can reduce the amount of work the browser needs to do to redraw that layer.

You can read more about this here:

https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas#promote_elements_that_move_or_fade

This improves our paint times from 0.71ms

https://i.imgur.com/3Asf2gu.png

to about 60us

https://i.imgur.com/fL2xCES.png

In most frames only the timer will be redrawn. By moving it into its own
browser layer, we can reduce the amount of work the browser needs to do
to redraw that layer.

You can read more about this here:

https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas#promote_elements_that_move_or_fade

This improves our paint times from 0.71ms

![https://i.imgur.com/3Asf2gu.png](https://i.imgur.com/3Asf2gu.png)

to about 60us

![https://i.imgur.com/fL2xCES.png](https://i.imgur.com/fL2xCES.png)
@CryZe CryZe added enhancement A new feature or general improvement to LiveSplit One. performance Performance is suboptimal and should be improved. layout rendering This affects the rendering of LiveSplit layouts. labels Jun 6, 2020
@CryZe CryZe requested a review from wooferzfg June 6, 2020 13:28
@CryZe
Copy link
Copy Markdown
Collaborator Author

CryZe commented Jun 6, 2020

I split out this PR from the other changes as this is a clear win, while the other changes don't seem to improve much (and possibly even regress the performance?!)

Copy link
Copy Markdown
Member

@wooferzfg wooferzfg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing some pretty big improvements.

Old code

chrome_dQLhFaNmC0

New code

chrome_4PuEmJ1LP2

@CryZe CryZe merged commit fb0d6f6 into LiveSplit:master Jun 6, 2020
CryZe added a commit to CryZe/livesplit-core that referenced this pull request Jun 8, 2021
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.
CryZe added a commit to CryZe/livesplit-core that referenced this pull request Jun 9, 2021
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.
@CryZe CryZe deleted the reduce-paint-time branch June 8, 2024 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement A new feature or general improvement to LiveSplit One. layout rendering This affects the rendering of LiveSplit layouts. performance Performance is suboptimal and should be improved.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants