dnkl/foot
41
2.0k
Fork
You've already forked foot
243

Faster rendering of scroll damage #12

Manually merged
dnkl merged 30 commits from scroll-damage-performance into master 2020年03月29日 12:08:11 +02:00
Owner
Copy link

This is an attempt at improving the rendering speed of interactive scrolling.

Today, this is done by memmoving the scrolled part of the pixmap. The fewer lines we're scrolling, the more data we have to memmove. Thus, normal single-line scrolling is slow.

The idea implemented here is this: what if we can scroll without moving any data? What if we instead can move the buffer pointers to point to the new top of the pixmap?

That part is actually pretty easy (for forward scrolling); we just have to increase the file size of the backing memory FD and create a new mmapping along with a new pixmap image instance and a new Wayland SHM buffer.

The problem is of course that this would consume an insane amount of memory.

So, is there some way to deal with this? Turns out the answer is yes. We can punch a "hole" from the beginning of the memfd file to the new start offset using fallocate(2) with FALLOC_FL_PUNCH_HOLE.

For small shifts of the offset, this turns out to be very fast. But it is on the other hand very slow when the offset is shifted by a large amount.

Luckily, this is precisely the opposite of the memmove method, which means we can memmove() when scrolling a large number of lines, and the new fallocate() based method when scrolling a small number of lines.

Another draw back of the new method is that the scrolled in area is completely uninitialized. This means we need to repair the bottom scroll region (when forward scrolling), and re-paint the window margins. This too can be very slow and thus we take this into account when determining which method to use.

TODO:

  • implement backward scrolling
  • investigate if it's worth restoring/repairing the scrolled out scrolling region too (right now, the new method is disabled if the scrolled out region is not empty)
  • implement restoration of scrolled out region

Closes #4

This is an attempt at improving the rendering speed of interactive scrolling. Today, this is done by memmoving the scrolled part of the pixmap. The fewer lines we're scrolling, the more data we have to memmove. Thus, normal single-line scrolling is slow. The idea implemented here is this: what if we can scroll without moving any data? What if we instead can move the buffer pointers to point to the new top of the pixmap? That part is actually pretty easy (for forward scrolling); we just have to increase the file size of the backing memory FD and create a new mmapping along with a new pixmap image instance and a new Wayland SHM buffer. The problem is of course that this would consume an insane amount of memory. So, is there some way to deal with this? Turns out the answer is yes. We can punch a "hole" from the beginning of the memfd file to the new start offset using `fallocate(2)` with `FALLOC_FL_PUNCH_HOLE`. For small shifts of the offset, this turns out to be **very** fast. But it is on the other hand very slow when the offset is shifted by a large amount. Luckily, this is precisely the opposite of the memmove method, which means we can `memmove()` when scrolling a large number of lines, and the new `fallocate()` based method when scrolling a small number of lines. Another draw back of the new method is that the scrolled in area is completely uninitialized. This means we need to repair the bottom scroll region (when forward scrolling), **and** re-paint the window margins. This too can be very slow and thus we take this into account when determining which method to use. TODO: - [X] implement backward scrolling - [X] investigate if it's worth restoring/repairing the scrolled **out** scrolling region too (right now, the new method is disabled if the scrolled out region is not empty) - [x] implement restoration of scrolled out region Closes https://codeberg.org/dnkl/foot/issues/4
Author
Owner
Copy link

investigate if it's worth restoring/repairing the scrolled out scrolling region too (right now, the new method is disabled if the scrolled out region is not empty)

It is. Big time.

> investigate if it's worth restoring/repairing the scrolled out scrolling region too (right now, the new method is disabled if the scrolled out region is not empty) It is. Big time.
dnkl changed title from (削除) WIP: faster rendering of scroll damage (削除ここまで) to Faster rendering of scroll damage 2020年03月24日 17:56:51 +01:00
Author
Owner
Copy link

This should be ready now. I'll be running this branch for a while before I merge it into master though, to make sure it doesn't break anything.

This should be ready now. I'll be running this branch for a while before I merge it into master though, to make sure it doesn't break anything.
dnkl closed this pull request 2020年03月29日 12:08:11 +02:00
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/foot!12
Reference in a new issue
dnkl/foot
No description provided.
Delete branch "scroll-damage-performance"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?