Reduce number of wl_surface_damage_buffer() calls #35

Closed
opened 1 year ago by dnkl · 1 comments
dnkl commented 1 year ago
Owner

Foot currently issues one damage call for each dirty row (for the whole row, regardless of number of dirty cells).

It should be trivial to merge consecutive dirty rows in a single damage.

Typically, another two calls are added for updating the cursor (erasing the old, rendering the new).

I think the whole special handling of the cursor can be removed, and instead done in the regular rendering of dirty rows, in which case the two damage calls would also be removed.

But most importantly, scrolling often ends up adding five calls - four for when the margin requires re-rendering, and another one for the scrolled area itself.

It should, in many cases, be possible to merge a couple of these. This is probably the hardest one.

Foot currently issues one damage call for each dirty row (for the _whole_ row, regardless of number of dirty cells). It should be trivial to merge consecutive dirty rows in a single damage. Typically, another two calls are added for updating the cursor (erasing the old, rendering the new). I _think_ the whole special handling of the cursor can be removed, and instead done in the regular rendering of dirty rows, in which case the two damage calls would also be removed. But most importantly, scrolling often ends up adding five calls - four for when the margin requires re-rendering, and another one for the scrolled area itself. It should, in many cases, be possible to merge a couple of these. This is probably the hardest one.
dnkl added the
performance
label 1 year ago
dnkl self-assigned this 1 year ago
dnkl commented 1 year ago
Poster
Owner

It should, in many cases, be possible to merge a couple of these. This is probably the hardest one.

Turned out this was the easiest one. While we do need to re-render the margins after having done an optimized "SHM-scroll", to ensure the backing buffer is correct, we don't have to tell the compositor we did; we already know the last frame had correctly rendered margins. Thus, there's no difference from the last frame, compared to the one being rendered, and thus there's no need to call wl_surface_damage_buffer().

This means applying scroll damage now issues one surface damage call, for the scrolled area. This is correct and cannot be avoided.

We'll then typically issue another one for the "new content". These two will typically overlap, but determining that basically comes down to us doing or own intersection calculation. So we don't even try.

> It should, in many cases, be possible to merge a couple of these. This is probably the hardest one. Turned out this was the easiest one. While we do need to re-render the margins after having done an optimized "SHM-scroll", to ensure the backing buffer is correct, we don't have to tell the compositor we did; we already know the last frame had correctly rendered margins. Thus, there's no difference from the last frame, compared to the one being rendered, and thus there's no need to call `wl_surface_damage_buffer()`. This means applying scroll damage now issues **one** surface damage call, for the scrolled area. This **is** correct and cannot be avoided. We'll then typically issue another one for the "new content". These two will typically overlap, but determining that basically comes down to us doing or own intersection calculation. So we don't even try.
dnkl closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Loading…
There is no content yet.