Our home rolled clip-to-cell code was, obviously, not correct.
The original problem was that we couldn't use pixman clipping since we
have multiple threads writing to the same pixman image, and thus there
would be races between the threads setting clipping.
The fix is actually simple - just instantiate one pixman
image (referencing the same backing image data) for each rendering
thread.
This both prevents accidental resizing of the memfd, and allows the
Wayland server to optimze reads from the buffer - it no longer has to
setup SIGBUS handlers.
This lessens the burden on (primarily) the compositor, since we no
longer tear down and re-create the SHM pool when scrolling.
The SHM pool is setup once, and its size is fixed at the maximum
allowed (512MB for now, 2GB would be possible).
This also allows us to mmap() the memfd once. The exposed raw pointer
is simply an offset from the memfd mmapping.
Note that this means e.g. rouge rendering code will be able to write
outside the buffer.
Finally, only do this if the caller explicitly wants to enable
scrolling. The memfd of other buffers are sized to the requested size.
* Impose a maximum memfd size limit. In theory, this can be
2GB (wl_shm_create_pool() is the limiting factor - its size argument
is an int32_t). For now, use 256MB.
This is mainly to reduce the amount of virtual address space used by
the compositor, which keeps at least one mmapping (of the entire
memfd) around. One mmapping *per terminal window* that is.
Given that we have 128TB with 48-bit virtual addresses, we could
probably bump this to 2GB without any issues. However, 256MB should
be enough.
TODO: check how much we typically move the offset when scrolling in
a fullscreen window on a 4K monitor. 256MB may turn out to be too
small.
On 32-bit shm_scroll() is completely disabled. There simply isn't
enough address space.
* Wrapping is done by moving the offset to "the other end" of the
memfd, and copying the buffer contents to the new, wrapped offset.
The "normal" scrolling code then does the actual scrolling. This
means we'll re-instantiate all objects twice when wrapping.
Implemented by truncating the file size and moving the offset
backwards. This means we can only reverse scroll when we've previously
scrolled forward.
TODO: figure out if we can somehow do fast reverse scrolling even
though offset is 0 (or well, less than required for scrolling).
This function "scrolls" the buffer by the specified number of (pixel)
rows.
The idea is move the image offset by re-sizing the underlying memfd
object. I.e. to scroll forward, increase the size of the memfd file,
and move the pixman image offset forward (and the Wayland SHM buffer
as well).
Only increasing the file size would, obviously, cause the memfd file
to grow indefinitely. To deal with this, we "punch" a whole from the
beginning of the file to the new offset. This frees the associated
memory.
Thus, while we have a memfd file whose size is (as seen by
e.g. fstat()) is ever growing, the actual file size is always the
original buffer size.
Some notes:
* FALLOC_FL_PUNCH_HOLE can be quite slow when the number of used pages
to drop is large.
* all normal fallocate() usages have been replaced with ftruncate(),
as this is *much* faster. fallocate() guarantees subsequent writes
wont fail. I.e. it actually reserves (disk) space. While it doesn't
allocate on-disk blocks for on-disk files, it *does* zero-initialize
the in-memory blocks. And this is slow. ftruncate() doesn't do this.
TODO: implement reverse scrolling (i.e. a negative row count).
When we need to create a new buffer (because the cache doesn't have
any buffers of correct size, or because they're all busy), purge
buffers with a size mismatch.
