mirrors/foot
1
0
Fork 0
mirror of https://codeberg.org/dnkl/foot.git synced 2026-02-05 04:06:08 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
foot/shm.c

1142 lines
31 KiB
C
Raw Normal View History

initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
#include "shm.h"
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
#include <stdio.h>
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
#include <string.h>
shm: handle EINTR in posix_fallocate()
2020-02-25 19:07:23 +01:00
#include <errno.h>
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
#include <unistd.h>
#include <limits.h>
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
#include <time.h>
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
#include <sys/types.h>
#include <sys/mman.h>
shm: prefer posix_fallocate over ftruncate
2020-02-15 19:46:00 +01:00
#include <fcntl.h>
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
#include <pixman.h>
tllist: is now an external "library", so use <> includes
2019-11-17 19:19:55 +01:00
#include <tllist.h>
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
#define LOG_MODULE "shm"
shm: associate a 'cookie' with each buffer When re-using a buffer from cache, only re-use ones with a matching cookie. This prevents contention between multiple terminal windows.
2019-11-02 00:33:37 +01:00
#define LOG_ENABLE_DBG 0
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
#include "log.h"
Print stack trace on assert() failure or when calling fatal_error() Note: this uses the __sanitizer_print_stack_trace() function from the AddressSanitizer runtime, so it only works when AddressSanitizer is in use.
2021-01-15 20:39:45 +00:00
#include "debug.h"
Replace GCC "unused" and "format" attributes with portable macros
2020-08-07 20:42:34 +01:00
#include "macros.h"
config: add tweak.min-stride-alignment This allows the user to configure the value by which a surface buffer's stride must be an even multiple of. This can be used to ensure the stride meets the GPU driver's requirements for direct import. Defaults to 256. Set to 0 to disable. Closes #2182
2025-10-04 09:29:56 +02:00
#include "stride.h"
Convert most dynamic allocations to use functions from xmalloc.h
2020-08-08 20:34:30 +01:00
#include "xmalloc.h"
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
shm: MAP_UNINITIALIZED is a linux only mmap flag
2020-10-10 11:29:04 +02:00
#if !defined(MAP_UNINITIALIZED)
#define MAP_UNINITIALIZED 0
#endif
shm: memfd_create: fallback to not using MFD_NOEXEC_SEAL MFD_NOEXEC_SEAL was introduced in linux 6.3. Kernels before that will *reject* memfd_create() calls that set it. This caused foot to exit (i.e. not start at all), when compiled on linux >= 6.3, but run on linux < 6.3. We _do_ want to use MFD_NOEXEC_SEAL, since a) our memory mapped really shouldn't be executable, and b) to silence a warning on linux >= 6.3. To handle all cases, first try *with* MFD_NOEXEC_SEAL. If that fails with EINVAL, retry *without* it. Closes #1514
2023-10-12 16:16:11 +02:00
#if !defined(MFD_NOEXEC_SEAL)
#define MFD_NOEXEC_SEAL 0
shm: move definition of FOOT_MFD_FLAGS to the top
2023-10-08 11:03:13 +02:00
#endif
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
#define TIME_SCROLL 0
shm: track busy buffers’ age, and add compile-time option to force double buffering By default, age all matching buffers that are busy (i.e. in use by the compositor). This allows us to detect whether we can apply the current frame’s damage directly, or if we need to prepare the buffer first (e.g. copy old buffer, or re-apply last frame’s damage etc).
2021-05-07 18:18:35 +02:00
#define FORCED_DOUBLE_BUFFERING 0
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
/*
* Maximum memfd size allowed.
*
* On 64-bit, we could in theory use up to 2GB (wk_shm_create_pool()
* is limited to int32_t), since we never mmap() the entire region.
*
* The compositor is different matter - it needs to mmap() the entire
* range, and *keep* the mapping for as long as is has buffers
* referencing it (thus - always). And if we open multiple terminals,
* then the required address space multiples...
*
* That said, 128TB (the total amount of available user address space
* on 64-bit) is *a lot*; we can fit 67108864 2GB memfds into
* that. But, let's be conservative for now.
*
* On 32-bit the available address space is too small and SHM
* scrolling is disabled.
shm: make max pool size user configurable (via a 'tweak' setting)
2020-03-25 20:48:02 +01:00
*
* Note: this is the _default_ size. It can be overridden by calling
* shm_set_max_pool_size();
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
*/
shm: make max pool size user configurable (via a 'tweak' setting)
2020-03-25 20:48:02 +01:00
static off_t max_pool_size = 512 * 1024 * 1024;
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
shm: verify the system supports FALLOC_FL_PUNCH_HOLE
2020-03-22 20:36:15 +01:00
static bool can_punch_hole = false;
static bool can_punch_hole_initialized = false;
config: add tweak.min-stride-alignment This allows the user to configure the value by which a surface buffer's stride must be an even multiple of. This can be used to ensure the stride meets the GPU driver's requirements for direct import. Defaults to 256. Set to 0 to disable. Closes #2182
2025-10-04 09:29:56 +02:00
static size_t min_stride_alignment = 0;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
struct buffer_pool {
int fd; /* memfd */
struct wl_shm_pool *wl_pool;
void *real_mmapped; /* Address returned from mmap */
size_t mmap_size; /* Size of mmap (>= size) */
size_t ref_count;
};
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
struct buffer_chain;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
struct buffer_private {
struct buffer public;
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
struct buffer_chain *chain;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
size_t ref_count;
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
bool busy; /* Owned by compositor */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
struct buffer_pool *pool;
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
off_t offset; /* Offset into memfd where data begins */
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
size_t size;
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
bool with_alpha;
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
bool scrollable;
render: when double-buffering, pre-apply previous frame's damage early Foot likes it when compositor releases buffer immediately, as that means we only have to re-render the cells that have changed since the last frame. For various reasons, not all compositors do this. In this case, foot is typically forced to switch between two buffers, i.e. double-buffer. In this case, each frame starts with copying over the damage from the previous frame, to the new frame. Then we start rendering the updated cells. Bringing over the previous frame's damage can be slow, if the changed area was large (e.g. when scrolling one or a few lines, or on full screen updates). It's also done single-threaded. Thus it not only slows down frame rendering, but pauses everything else (i.e. input processing). All in all, it reduces performance and increases input latency. But we don't have to wait until it's time to render a frame to copy over the previous frame's damage. We can do that as soon as the compositor has released the buffer (for the frame _before_ the previous frame). And we can do this in a thread. This frees up foot to continue processing input, and reduces frame rendering time since we can now start rendering the modified cells immediately, without first doing a large memcpy(3). In worst case scenarios (or perhaps we should consider them best case scenarios...), I've seen up to a 10x performance increase in frame rendering times (this obviously does *not* include the time it takes to copy over the previous frame's damage, since that doesn't affect neither input processing nor frame rendering). Implemented by adding a callback mechanism to the shm abstraction layer. Use it for the grid buffers, and kick off a thread that copies the previous frame's damage, and resets the buffers age to 0 (so that foot understands it can start render to it immediately when it later needs to render a frame). Since we have certain way of knowing if a compositor releases buffers immediately or not, use a bit of heuristics; if we see 10 consecutive non-immediate releases (that is, we reset the counter as soon as we do see an immediate release), this new "pre-apply damage" logic is enabled. It can be force-disabled with tweak.pre-apply-damage=no. We also need to take care to wait for the thread before resetting the render's "last_buf" pointer (or we'll SEGFAULT in the thread...). We must also ensure we wait for the thread to finish before we start rendering a new frame. Under normal circumstances, the wait time is always 0, the thread has almost always finished long before we need to render the next frame. But it _can_ happen. Closes #2188
2025-10-05 10:48:36 +02:00
void (*release_cb)(struct buffer *buf, void *data);
void *cb_data;
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
};
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
struct buffer_chain {
tll(struct buffer_private *) bufs;
struct wl_shm *shm;
size_t pix_instances;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
bool scrollable;
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
pixman_format_code_t pixman_fmt_without_alpha;
enum wl_shm_format shm_format_without_alpha;
pixman_format_code_t pixman_fmt_with_alpha;
enum wl_shm_format shm_format_with_alpha;
render: when double-buffering, pre-apply previous frame's damage early Foot likes it when compositor releases buffer immediately, as that means we only have to re-render the cells that have changed since the last frame. For various reasons, not all compositors do this. In this case, foot is typically forced to switch between two buffers, i.e. double-buffer. In this case, each frame starts with copying over the damage from the previous frame, to the new frame. Then we start rendering the updated cells. Bringing over the previous frame's damage can be slow, if the changed area was large (e.g. when scrolling one or a few lines, or on full screen updates). It's also done single-threaded. Thus it not only slows down frame rendering, but pauses everything else (i.e. input processing). All in all, it reduces performance and increases input latency. But we don't have to wait until it's time to render a frame to copy over the previous frame's damage. We can do that as soon as the compositor has released the buffer (for the frame _before_ the previous frame). And we can do this in a thread. This frees up foot to continue processing input, and reduces frame rendering time since we can now start rendering the modified cells immediately, without first doing a large memcpy(3). In worst case scenarios (or perhaps we should consider them best case scenarios...), I've seen up to a 10x performance increase in frame rendering times (this obviously does *not* include the time it takes to copy over the previous frame's damage, since that doesn't affect neither input processing nor frame rendering). Implemented by adding a callback mechanism to the shm abstraction layer. Use it for the grid buffers, and kick off a thread that copies the previous frame's damage, and resets the buffers age to 0 (so that foot understands it can start render to it immediately when it later needs to render a frame). Since we have certain way of knowing if a compositor releases buffers immediately or not, use a bit of heuristics; if we see 10 consecutive non-immediate releases (that is, we reset the counter as soon as we do see an immediate release), this new "pre-apply damage" logic is enabled. It can be force-disabled with tweak.pre-apply-damage=no. We also need to take care to wait for the thread before resetting the render's "last_buf" pointer (or we'll SEGFAULT in the thread...). We must also ensure we wait for the thread to finish before we start rendering a new frame. Under normal circumstances, the wait time is always 0, the thread has almost always finished long before we need to render the next frame. But it _can_ happen. Closes #2188
2025-10-05 10:48:36 +02:00
void (*release_cb)(struct buffer *buf, void *data);
void *cb_data;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
};
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
static tll(struct buffer_private *) deferred;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm: #ifdef conditional code to measure total size of SHM allocations
2020-04-18 12:24:40 +02:00
#undef MEASURE_SHM_ALLOCS
#if defined(MEASURE_SHM_ALLOCS)
static size_t max_alloced = 0;
#endif
shm: make max pool size user configurable (via a 'tweak' setting)
2020-03-25 20:48:02 +01:00
void
shm_set_max_pool_size(off_t _max_pool_size)
{
max_pool_size = _max_pool_size;
}
config: add tweak.min-stride-alignment This allows the user to configure the value by which a surface buffer's stride must be an even multiple of. This can be used to ensure the stride meets the GPU driver's requirements for direct import. Defaults to 256. Set to 0 to disable. Closes #2182
2025-10-04 09:29:56 +02:00
void
shm_set_min_stride_alignment(size_t _min_stride_alignment)
{
min_stride_alignment = _min_stride_alignment;
}
shm: purge unused buffers 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.
2019-11-02 00:35:02 +01:00
static void
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
buffer_destroy_dont_close(struct buffer *buf)
shm: purge unused buffers 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.
2019-11-02 00:35:02 +01:00
{
render: re-write cell clipping to use pixman destination clipping 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.
2020-06-04 15:39:19 +02:00
if (buf->pix != NULL) {
for (size_t i = 0; i < buf->pix_instances; i++)
if (buf->pix[i] != NULL)
pixman_image_unref(buf->pix[i]);
}
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
if (buf->wl_buf != NULL)
wl_buffer_destroy(buf->wl_buf);
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
render: re-write cell clipping to use pixman destination clipping 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.
2020-06-04 15:39:19 +02:00
free(buf->pix);
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
buf->pix = NULL;
buf->wl_buf = NULL;
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
buf->data = NULL;
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
static void
pool_unref(struct buffer_pool *pool)
{
if (pool == NULL)
return;
xassert(pool->ref_count > 0);
pool->ref_count--;
if (pool->ref_count > 0)
return;
if (pool->real_mmapped != MAP_FAILED)
munmap(pool->real_mmapped, pool->mmap_size);
if (pool->wl_pool != NULL)
wl_shm_pool_destroy(pool->wl_pool);
if (pool->fd >= 0)
close(pool->fd);
pool->real_mmapped = MAP_FAILED;
pool->wl_pool = NULL;
pool->fd = -1;
free(pool);
}
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
static void
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
buffer_destroy(struct buffer_private *buf)
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
{
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
buffer_destroy_dont_close(&buf->public);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
pool_unref(buf->pool);
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
buf->pool = NULL;
shm: add damage tracking to buffer
2021-05-07 20:20:47 +02:00
render: more fine-grained wayland surface damage tracking Before this patch. Wayland surface damage tracking was done on a per-row basis. That is, even if just one cell was updated, the entire row was "damaged". Now, damage is per cell. This hopefully results in lower latencies in many use cases, and especially on high DPI monitors.
2023-10-07 16:23:09 +02:00
for (size_t i = 0; i < buf->public.pix_instances; i++)
pixman_region32_fini(&buf->public.dirty[i]);
free(buf->public.dirty);
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
free(buf);
shm: purge unused buffers 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.
2019-11-02 00:35:02 +01:00
}
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
static bool
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
buffer_unref_no_remove_from_chain(struct buffer_private *buf)
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
{
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
xassert(buf->ref_count > 0);
buf->ref_count--;
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
if (buf->ref_count > 0)
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
return false;
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
if (buf->busy)
tll_push_back(deferred, buf);
else
buffer_destroy(buf);
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
return true;
}
shm: make max pool size user configurable (via a 'tweak' setting)
2020-03-25 20:48:02 +01:00
void
shm_fini(void)
{
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
LOG_DBG("deferred buffers: %zu", tll_length(deferred));
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
tll_foreach(deferred, it) {
buffer_destroy(it->item);
tll_remove(deferred, it);
}
shm: #ifdef conditional code to measure total size of SHM allocations
2020-04-18 12:24:40 +02:00
#if defined(MEASURE_SHM_ALLOCS) && MEASURE_SHM_ALLOCS
LOG_INFO("max total allocations was: %zu MB", max_alloced / 1024 / 1024);
#endif
shm: make max pool size user configurable (via a 'tweak' setting)
2020-03-25 20:48:02 +01:00
}
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
static void
buffer_release(void *data, struct wl_buffer *wl_buffer)
{
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
struct buffer_private *buffer = data;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
xassert(buffer->public.wl_buf == wl_buffer);
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(buffer->busy);
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
buffer->busy = false;
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
if (buffer->ref_count == 0) {
bool found = false;
tll_foreach(deferred, it) {
if (it->item == buffer) {
found = true;
tll_remove(deferred, it);
break;
}
}
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
buffer_destroy(buffer);
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
xassert(found);
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
if (!found)
LOG_WARN("deferred delete: buffer not on the 'deferred' list");
render: when double-buffering, pre-apply previous frame's damage early Foot likes it when compositor releases buffer immediately, as that means we only have to re-render the cells that have changed since the last frame. For various reasons, not all compositors do this. In this case, foot is typically forced to switch between two buffers, i.e. double-buffer. In this case, each frame starts with copying over the damage from the previous frame, to the new frame. Then we start rendering the updated cells. Bringing over the previous frame's damage can be slow, if the changed area was large (e.g. when scrolling one or a few lines, or on full screen updates). It's also done single-threaded. Thus it not only slows down frame rendering, but pauses everything else (i.e. input processing). All in all, it reduces performance and increases input latency. But we don't have to wait until it's time to render a frame to copy over the previous frame's damage. We can do that as soon as the compositor has released the buffer (for the frame _before_ the previous frame). And we can do this in a thread. This frees up foot to continue processing input, and reduces frame rendering time since we can now start rendering the modified cells immediately, without first doing a large memcpy(3). In worst case scenarios (or perhaps we should consider them best case scenarios...), I've seen up to a 10x performance increase in frame rendering times (this obviously does *not* include the time it takes to copy over the previous frame's damage, since that doesn't affect neither input processing nor frame rendering). Implemented by adding a callback mechanism to the shm abstraction layer. Use it for the grid buffers, and kick off a thread that copies the previous frame's damage, and resets the buffers age to 0 (so that foot understands it can start render to it immediately when it later needs to render a frame). Since we have certain way of knowing if a compositor releases buffers immediately or not, use a bit of heuristics; if we see 10 consecutive non-immediate releases (that is, we reset the counter as soon as we do see an immediate release), this new "pre-apply damage" logic is enabled. It can be force-disabled with tweak.pre-apply-damage=no. We also need to take care to wait for the thread before resetting the render's "last_buf" pointer (or we'll SEGFAULT in the thread...). We must also ensure we wait for the thread to finish before we start rendering a new frame. Under normal circumstances, the wait time is always 0, the thread has almost always finished long before we need to render the next frame. But it _can_ happen. Closes #2188
2025-10-05 10:48:36 +02:00
} else {
if (buffer->release_cb != NULL) {
buffer->release_cb(&buffer->public, buffer->cb_data);
}
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
}
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
}
static const struct wl_buffer_listener buffer_listener = {
.release = &buffer_release,
};
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
static size_t
page_size(void)
{
static size_t size = 0;
if (size == 0) {
fix some buggy comparisons relating to signed/unsigned types
2020-08-25 19:39:17 +01:00
long n = sysconf(_SC_PAGE_SIZE);
if (n <= 0) {
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
LOG_ERRNO("failed to get page size");
size = 4096;
fix some buggy comparisons relating to signed/unsigned types
2020-08-25 19:39:17 +01:00
} else {
size = (size_t)n;
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
}
}
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(size > 0);
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
return size;
}
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
static bool
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
instantiate_offset(struct buffer_private *buf, off_t new_offset)
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
{
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
xassert(buf->public.data == NULL);
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
xassert(buf->public.pix == NULL);
xassert(buf->public.wl_buf == NULL);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
xassert(buf->pool != NULL);
const struct buffer_pool *pool = buf->pool;
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
void *mmapped = MAP_FAILED;
struct wl_buffer *wl_buf = NULL;
notify: don't close FD 0 This fixes a regression where closing a terminal instance, or hard- or soft-resetting a terminal caused FD 0 to be closed. This meant it became re-usable. Usually, by memfd_create() when allocating a new surface buffer. So far nothing _really_ bad has happened. But what if FD 0 is now used by a memfd, and we close _another_ terminal instance? This causes our memfd to be closed. And then, when e.g. trying to scroll the terminal content: fallocate() fails with bad FD.
2024-07-30 16:33:19 +02:00
pixman_image_t **pix = xcalloc(buf->public.pix_instances, sizeof(pix[0]));
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
mmapped = (uint8_t *)pool->real_mmapped + new_offset;
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
wl_buf = wl_shm_pool_create_buffer(
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
pool->wl_pool, new_offset,
buf->public.width, buf->public.height, buf->public.stride,
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
buf->with_alpha
? buf->chain->shm_format_with_alpha
: buf->chain->shm_format_without_alpha);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
if (wl_buf == NULL) {
LOG_ERR("failed to create SHM buffer");
goto err;
}
/* One pixman image for each worker thread (do we really need multiple?) */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
for (size_t i = 0; i < buf->public.pix_instances; i++) {
render: re-write cell clipping to use pixman destination clipping 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.
2020-06-04 15:39:19 +02:00
pix[i] = pixman_image_create_bits_no_clear(
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
buf->with_alpha
? buf->chain->pixman_fmt_with_alpha
: buf->chain->pixman_fmt_without_alpha,
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
buf->public.width, buf->public.height,
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
(uint32_t *)mmapped, buf->public.stride);
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
render: re-write cell clipping to use pixman destination clipping 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.
2020-06-04 15:39:19 +02:00
if (pix[i] == NULL) {
LOG_ERR("failed to create pixman image");
goto err;
}
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
}
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
buf->public.data = mmapped;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
buf->public.wl_buf = wl_buf;
buf->public.pix = pix;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
buf->offset = new_offset;
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
wl_buffer_add_listener(wl_buf, &buffer_listener, buf);
return true;
err:
render: re-write cell clipping to use pixman destination clipping 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.
2020-06-04 15:39:19 +02:00
if (pix != NULL) {
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
for (size_t i = 0; i < buf->public.pix_instances; i++)
render: re-write cell clipping to use pixman destination clipping 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.
2020-06-04 15:39:19 +02:00
if (pix[i] != NULL)
pixman_image_unref(pix[i]);
}
free(pix);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
if (wl_buf != NULL)
wl_buffer_destroy(wl_buf);
abort();
return false;
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
static void NOINLINE
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
get_new_buffers(struct buffer_chain *chain, size_t count,
int widths[static count], int heights[static count],
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
struct buffer *bufs[static count], bool with_alpha,
bool immediate_purge)
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
{
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
xassert(count == 1 || !chain->scrollable);
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
/*
* No existing buffer available. Create a new one by:
*
* 1. open a memory backed "file" with memfd_create()
Remove all references to cairo; we now use pixman only
2019-08-16 22:11:22 +02:00
* 2. mmap() the memory file, to be used by the pixman image
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
* 3. create a wayland shm buffer for the same memory file
*
Remove all references to cairo; we now use pixman only
2019-08-16 22:11:22 +02:00
* The pixman image and the wayland buffer are now sharing memory.
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
*/
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
int stride[count];
int sizes[count];
size_t total_size = 0;
for (size_t i = 0; i < count; i++) {
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
stride[i] = stride_for_format_and_width(
config: tweak.surface-bit-depth: add support for 16-bit surfaces This adds supports for 16-bit surfaces, using the new PIXMAN_a16b16g16r16 buffer format. This maps to WL_SHM_FORMAT_ABGR16161616 (little-endian). Use the new 16-bit surfaces by default, when gamma-correct-blending=yes.
2025-05-01 09:37:47 +02:00
with_alpha
? chain->pixman_fmt_with_alpha
: chain->pixman_fmt_without_alpha,
widths[i]);
config: add tweak.min-stride-alignment This allows the user to configure the value by which a surface buffer's stride must be an even multiple of. This can be used to ensure the stride meets the GPU driver's requirements for direct import. Defaults to 256. Set to 0 to disable. Closes #2182
2025-10-04 09:29:56 +02:00
if (min_stride_alignment > 0) {
const size_t m = min_stride_alignment;
stride[i] = (stride[i] + m - 1) / m * m;
}
xassert(min_stride_alignment == 0 || stride[i] % min_stride_alignment == 0);
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
sizes[i] = stride[i] * heights[i];
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
total_size += sizes[i];
}
fix crashes when resizing after CSD enabled at runtime with csd.size = 0
2021-09-23 22:17:43 +00:00
if (total_size == 0)
return;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
int pool_fd = -1;
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
void *real_mmapped = MAP_FAILED;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
struct wl_shm_pool *wl_pool = NULL;
struct buffer_pool *pool = NULL;
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
/* Backing memory for SHM */
shm: unbreak build without memfd_create New FreeBSD versions have memfd_create but other BSDs don't. pgo/pgo.c:260:22: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ pgo/pgo.c:260:52: error: use of undeclared identifier 'MFD_CLOEXEC' int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ shm.c:13:10: fatal error: 'linux/mman.h' file not found #include <linux/mman.h> ^~~~~~~~~~~~~~ shm.c:277:15: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:60: error: use of undeclared identifier 'MFD_CLOEXEC' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:74: error: use of undeclared identifier 'MFD_ALLOW_SEALING' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:339:15: error: use of undeclared identifier 'F_SEAL_GROW' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:29: error: use of undeclared identifier 'F_SEAL_SHRINK' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:71: error: use of undeclared identifier 'F_SEAL_SEAL' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:338:24: error: use of undeclared identifier 'F_ADD_SEALS' if (fcntl(pool_fd, F_ADD_SEALS, ^
2021-01-19 14:20:55 +00:00
#if defined(MEMFD_CREATE)
shm: memfd_create: fallback to not using MFD_NOEXEC_SEAL MFD_NOEXEC_SEAL was introduced in linux 6.3. Kernels before that will *reject* memfd_create() calls that set it. This caused foot to exit (i.e. not start at all), when compiled on linux >= 6.3, but run on linux < 6.3. We _do_ want to use MFD_NOEXEC_SEAL, since a) our memory mapped really shouldn't be executable, and b) to silence a warning on linux >= 6.3. To handle all cases, first try *with* MFD_NOEXEC_SEAL. If that fails with EINVAL, retry *without* it. Closes #1514
2023-10-12 16:16:11 +02:00
/*
* Older kernels reject MFD_NOEXEC_SEAL with EINVAL. Try first
* *with* it, and if that fails, try again *without* it.
*/
errno = 0;
pool_fd = memfd_create(
"foot-wayland-shm-buffer-pool",
MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_NOEXEC_SEAL);
shm: minor optimization Don't retry memfd_create() without MFD_NOEXEC_SEAL is 0. The overall logic is this: * Try memfd_create() with MFD_NOEXEC_SEAL * If that fails (which it does, on older kernels), try without the flag If compiling against an older kernel, or on a system that doesn't support the noexec seal, MFD_NOEXEC_SEAL is 0. In this case, there's little point in retrying memfd_create a second time, with the exact same set of flags.
2024-05-22 14:06:15 +02:00
if (pool_fd < 0 && errno == EINVAL && MFD_NOEXEC_SEAL != 0) {
shm: memfd_create: fallback to not using MFD_NOEXEC_SEAL MFD_NOEXEC_SEAL was introduced in linux 6.3. Kernels before that will *reject* memfd_create() calls that set it. This caused foot to exit (i.e. not start at all), when compiled on linux >= 6.3, but run on linux < 6.3. We _do_ want to use MFD_NOEXEC_SEAL, since a) our memory mapped really shouldn't be executable, and b) to silence a warning on linux >= 6.3. To handle all cases, first try *with* MFD_NOEXEC_SEAL. If that fails with EINVAL, retry *without* it. Closes #1514
2023-10-12 16:16:11 +02:00
pool_fd = memfd_create(
"foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING);
}
shm: unbreak build without memfd_create New FreeBSD versions have memfd_create but other BSDs don't. pgo/pgo.c:260:22: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ pgo/pgo.c:260:52: error: use of undeclared identifier 'MFD_CLOEXEC' int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ shm.c:13:10: fatal error: 'linux/mman.h' file not found #include <linux/mman.h> ^~~~~~~~~~~~~~ shm.c:277:15: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:60: error: use of undeclared identifier 'MFD_CLOEXEC' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:74: error: use of undeclared identifier 'MFD_ALLOW_SEALING' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:339:15: error: use of undeclared identifier 'F_SEAL_GROW' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:29: error: use of undeclared identifier 'F_SEAL_SHRINK' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:71: error: use of undeclared identifier 'F_SEAL_SEAL' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:338:24: error: use of undeclared identifier 'F_ADD_SEALS' if (fcntl(pool_fd, F_ADD_SEALS, ^
2021-01-19 14:20:55 +00:00
#elif defined(__FreeBSD__)
// memfd_create on FreeBSD 13 is SHM_ANON without sealing support
pool_fd = shm_open(SHM_ANON, O_RDWR | O_CLOEXEC, 0600);
#else
char name[] = "/tmp/foot-wayland-shm-buffer-pool-XXXXXX";
pool_fd = mkostemp(name, O_CLOEXEC);
unlink(name);
#endif
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
if (pool_fd == -1) {
LOG_ERRNO("failed to create SHM backing memory file");
goto err;
}
shm: page-align the memfd size (also needed for GPU direct import)
2025-10-04 10:50:38 +02:00
const size_t page_sz = page_size();
shm: don’t check for __i386__ and __x86_64__ - there are other architectures out there Instead, check for __SIZEOF_POINTER__ == 8, since what we’re really interested in is whether we have enough virtual address space or not.
2021-01-21 12:39:51 +01:00
#if __SIZEOF_POINTER__ == 8
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
off_t offset = chain->scrollable && max_pool_size > 0
shm: page-align the memfd size (also needed for GPU direct import)
2025-10-04 10:50:38 +02:00
? (max_pool_size / 4) & ~(page_sz - 1)
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
: 0;
off_t memfd_size = chain->scrollable && max_pool_size > 0
? max_pool_size
: total_size;
shm: don’t check for __i386__ and __x86_64__ - there are other architectures out there Instead, check for __SIZEOF_POINTER__ == 8, since what we’re really interested in is whether we have enough virtual address space or not.
2021-01-21 12:39:51 +01:00
#else
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
off_t offset = 0;
off_t memfd_size = total_size;
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
#endif
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
shm: page-align the memfd size (also needed for GPU direct import)
2025-10-04 10:50:38 +02:00
/* Page align */
memfd_size = (memfd_size + page_sz - 1) & ~(page_sz - 1);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
LOG_DBG("memfd-size: %lu, initial offset: %lu", memfd_size, offset);
shm: make max pool size user configurable (via a 'tweak' setting)
2020-03-25 20:48:02 +01:00
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
if (ftruncate(pool_fd, memfd_size) == -1) {
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
LOG_ERRNO("failed to set size of SHM backing memory file");
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
goto err;
}
shm: verify the system supports FALLOC_FL_PUNCH_HOLE
2020-03-22 20:36:15 +01:00
if (!can_punch_hole_initialized) {
can_punch_hole_initialized = true;
shm: don’t check for __i386__ and __x86_64__ - there are other architectures out there Instead, check for __SIZEOF_POINTER__ == 8, since what we’re really interested in is whether we have enough virtual address space or not.
2021-01-21 12:39:51 +01:00
#if __SIZEOF_POINTER__ == 8 && defined(FALLOC_FL_PUNCH_HOLE)
shm: verify the system supports FALLOC_FL_PUNCH_HOLE
2020-03-22 20:36:15 +01:00
can_punch_hole = fallocate(
pool_fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 0, 1) == 0;
shm: print performance warning when FALLOC_FL_PUNCH_HOLE isn't supported
2020-03-22 21:04:00 +01:00
if (!can_punch_hole) {
LOG_WARN(
"fallocate(FALLOC_FL_PUNCH_HOLE) not "
"supported (%s): expect lower performance", strerror(errno));
}
shm: don't even try to punch a memfd hole in 32-bit This ensures we don't issue a warning if we fail, something that will just confuse users, as SHM scrolling is disabled in 32-bit anyway.
2020-08-11 17:22:12 +02:00
#else
/* This is mostly to make sure we skip the warning issued
* above */
can_punch_hole = false;
#endif
shm: verify the system supports FALLOC_FL_PUNCH_HOLE
2020-03-22 20:36:15 +01:00
}
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
if (chain->scrollable && !can_punch_hole) {
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
offset = 0;
memfd_size = total_size;
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
chain->scrollable = false;
shm: handle ftruncate failure
2020-03-25 18:32:41 +01:00
shm: page-align the memfd size (also needed for GPU direct import)
2025-10-04 10:50:38 +02:00
/* Page align */
memfd_size = (memfd_size + page_sz - 1) & ~(page_sz - 1);
shm: handle ftruncate failure
2020-03-25 18:32:41 +01:00
if (ftruncate(pool_fd, memfd_size) < 0) {
LOG_ERRNO("failed to set size of SHM backing memory file");
goto err;
}
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
}
real_mmapped = mmap(
NULL, memfd_size, PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_UNINITIALIZED, pool_fd, 0);
if (real_mmapped == MAP_FAILED) {
LOG_ERRNO("failed to mmap SHM backing memory file");
goto err;
}
shm: unbreak build without memfd_create New FreeBSD versions have memfd_create but other BSDs don't. pgo/pgo.c:260:22: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ pgo/pgo.c:260:52: error: use of undeclared identifier 'MFD_CLOEXEC' int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ shm.c:13:10: fatal error: 'linux/mman.h' file not found #include <linux/mman.h> ^~~~~~~~~~~~~~ shm.c:277:15: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:60: error: use of undeclared identifier 'MFD_CLOEXEC' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:74: error: use of undeclared identifier 'MFD_ALLOW_SEALING' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:339:15: error: use of undeclared identifier 'F_SEAL_GROW' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:29: error: use of undeclared identifier 'F_SEAL_SHRINK' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:71: error: use of undeclared identifier 'F_SEAL_SEAL' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:338:24: error: use of undeclared identifier 'F_ADD_SEALS' if (fcntl(pool_fd, F_ADD_SEALS, ^
2021-01-19 14:20:55 +00:00
#if defined(MEMFD_CREATE)
shm: seal the memfd 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.
2020-03-25 18:30:21 +01:00
/* Seal file - we no longer allow any kind of resizing */
/* TODO: wayland mmaps(PROT_WRITE), for some unknown reason, hence we cannot use F_SEAL_FUTURE_WRITE */
if (fcntl(pool_fd, F_ADD_SEALS,
F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0)
{
LOG_ERRNO("failed to seal SHM backing memory file");
shm: memfd seal failures are not fatal errors
2020-04-03 20:14:53 +02:00
/* This is not a fatal error */
shm: seal the memfd 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.
2020-03-25 18:30:21 +01:00
}
shm: unbreak build without memfd_create New FreeBSD versions have memfd_create but other BSDs don't. pgo/pgo.c:260:22: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ pgo/pgo.c:260:52: error: use of undeclared identifier 'MFD_CLOEXEC' int mem_fd = memfd_create("foot-pgo-ptmx", MFD_CLOEXEC); ^ shm.c:13:10: fatal error: 'linux/mman.h' file not found #include <linux/mman.h> ^~~~~~~~~~~~~~ shm.c:277:15: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration] pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:60: error: use of undeclared identifier 'MFD_CLOEXEC' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:277:74: error: use of undeclared identifier 'MFD_ALLOW_SEALING' pool_fd = memfd_create("foot-wayland-shm-buffer-pool", MFD_CLOEXEC | MFD_ALLOW_SEALING); ^ shm.c:339:15: error: use of undeclared identifier 'F_SEAL_GROW' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:29: error: use of undeclared identifier 'F_SEAL_SHRINK' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:339:71: error: use of undeclared identifier 'F_SEAL_SEAL' F_SEAL_GROW | F_SEAL_SHRINK | /*F_SEAL_FUTURE_WRITE |*/ F_SEAL_SEAL) < 0) ^ shm.c:338:24: error: use of undeclared identifier 'F_ADD_SEALS' if (fcntl(pool_fd, F_ADD_SEALS, ^
2021-01-19 14:20:55 +00:00
#endif
shm: seal the memfd 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.
2020-03-25 18:30:21 +01:00
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
wl_pool = wl_shm_create_pool(chain->shm, pool_fd, memfd_size);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
if (wl_pool == NULL) {
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
LOG_ERR("failed to create SHM pool");
goto err;
}
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
pool = xmalloc(sizeof(*pool));
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
if (pool == NULL) {
LOG_ERRNO("failed to allocate buffer pool");
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
goto err;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
}
*pool = (struct buffer_pool){
.fd = pool_fd,
.wl_pool = wl_pool,
.real_mmapped = real_mmapped,
.mmap_size = memfd_size,
.ref_count = 0,
};
for (size_t i = 0; i < count; i++) {
shm: get_many(): allow “NULL” buffers - buffers where width or height is 0 When a zero-sized buffer is requested, simply return a NULL buffer, instead of crashing with a Wayland protocol error. This makes it easier to request many buffers, where some may be zero-sized, without having to pack the width/height and bufs arrays.
2021-07-18 16:44:49 +02:00
if (sizes[i] == 0) {
bufs[i] = NULL;
continue;
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
/* Push to list of available buffers, but marked as 'busy' */
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
struct buffer_private *buf = xmalloc(sizeof(*buf));
*buf = (struct buffer_private){
.public = {
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
.width = widths[i],
.height = heights[i],
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
.stride = stride[i],
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
.pix_instances = chain->pix_instances,
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
.age = 1234, /* Force a full repaint */
},
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
.chain = chain,
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
.ref_count = immediate_purge ? 0 : 1,
.busy = true,
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
.with_alpha = with_alpha,
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
.pool = pool,
.offset = 0,
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
.size = sizes[i],
.scrollable = chain->scrollable,
render: when double-buffering, pre-apply previous frame's damage early Foot likes it when compositor releases buffer immediately, as that means we only have to re-render the cells that have changed since the last frame. For various reasons, not all compositors do this. In this case, foot is typically forced to switch between two buffers, i.e. double-buffer. In this case, each frame starts with copying over the damage from the previous frame, to the new frame. Then we start rendering the updated cells. Bringing over the previous frame's damage can be slow, if the changed area was large (e.g. when scrolling one or a few lines, or on full screen updates). It's also done single-threaded. Thus it not only slows down frame rendering, but pauses everything else (i.e. input processing). All in all, it reduces performance and increases input latency. But we don't have to wait until it's time to render a frame to copy over the previous frame's damage. We can do that as soon as the compositor has released the buffer (for the frame _before_ the previous frame). And we can do this in a thread. This frees up foot to continue processing input, and reduces frame rendering time since we can now start rendering the modified cells immediately, without first doing a large memcpy(3). In worst case scenarios (or perhaps we should consider them best case scenarios...), I've seen up to a 10x performance increase in frame rendering times (this obviously does *not* include the time it takes to copy over the previous frame's damage, since that doesn't affect neither input processing nor frame rendering). Implemented by adding a callback mechanism to the shm abstraction layer. Use it for the grid buffers, and kick off a thread that copies the previous frame's damage, and resets the buffers age to 0 (so that foot understands it can start render to it immediately when it later needs to render a frame). Since we have certain way of knowing if a compositor releases buffers immediately or not, use a bit of heuristics; if we see 10 consecutive non-immediate releases (that is, we reset the counter as soon as we do see an immediate release), this new "pre-apply damage" logic is enabled. It can be force-disabled with tweak.pre-apply-damage=no. We also need to take care to wait for the thread before resetting the render's "last_buf" pointer (or we'll SEGFAULT in the thread...). We must also ensure we wait for the thread to finish before we start rendering a new frame. Under normal circumstances, the wait time is always 0, the thread has almost always finished long before we need to render the next frame. But it _can_ happen. Closes #2188
2025-10-05 10:48:36 +02:00
.release_cb = chain->release_cb,
.cb_data = chain->cb_data,
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
};
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
if (!instantiate_offset(buf, offset)) {
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
free(buf);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
goto err;
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
}
if (immediate_purge)
tll_push_front(deferred, buf);
else
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
tll_push_front(chain->bufs, buf);
shm: #ifdef conditional code to measure total size of SHM allocations
2020-04-18 12:24:40 +02:00
Replace unchecked allocations with calls to xmalloc.h functions
2024-01-25 07:03:50 +00:00
buf->public.dirty = xmalloc(
render: more fine-grained wayland surface damage tracking Before this patch. Wayland surface damage tracking was done on a per-row basis. That is, even if just one cell was updated, the entire row was "damaged". Now, damage is per cell. This hopefully results in lower latencies in many use cases, and especially on high DPI monitors.
2023-10-07 16:23:09 +02:00
chain->pix_instances * sizeof(buf->public.dirty[0]));
for (size_t j = 0; j < chain->pix_instances; j++)
pixman_region32_init(&buf->public.dirty[j]);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
pool->ref_count++;
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
offset += buf->size;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
bufs[i] = &buf->public;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
}
shm: add damage tracking to buffer
2021-05-07 20:20:47 +02:00
shm: #ifdef conditional code to measure total size of SHM allocations
2020-04-18 12:24:40 +02:00
#if defined(MEASURE_SHM_ALLOCS) && MEASURE_SHM_ALLOCS
{
size_t currently_alloced = 0;
tll_foreach(buffers, it)
currently_alloced += it->item.size;
if (currently_alloced > max_alloced)
max_alloced = currently_alloced;
}
#endif
fix crashes when resizing after CSD enabled at runtime with csd.size = 0
2021-09-23 22:17:43 +00:00
if (!(bufs[0] && shm_can_scroll(bufs[0]))) {
Don't use fancy Unicode quotes, stick to ASCII
2024-02-06 12:36:45 +01:00
/* We only need to keep the pool FD open if we're going to SHM
shm: close pool FD if buffer doesn’t support SHM scrolling The only reason to keep the pool FD open is if we’re going to SHM scroll the buffer; we need the FD for fallocate(FALLOC_FL_PUNCH_HOLE). In all other cases, there’s absolutely no need to keep the FD open. Thus, close it as soon as we’ve instantiated the buffer. This frees up FDs, and help keep foot from FD ulimit.
2021-07-11 10:22:47 +02:00
* scroll it */
close(pool_fd);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
pool->fd = -1;
shm: close pool FD if buffer doesn’t support SHM scrolling The only reason to keep the pool FD open is if we’re going to SHM scroll the buffer; we need the FD for fallocate(FALLOC_FL_PUNCH_HOLE). In all other cases, there’s absolutely no need to keep the FD open. Thus, close it as soon as we’ve instantiated the buffer. This frees up FDs, and help keep foot from FD ulimit.
2021-07-11 10:22:47 +02:00
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
return;
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
err:
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
pool_unref(pool);
if (wl_pool != NULL)
wl_shm_pool_destroy(wl_pool);
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
if (real_mmapped != MAP_FAILED)
munmap(real_mmapped, memfd_size);
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
if (pool_fd != -1)
close(pool_fd);
shm: we don't really handle SHM failures, so just abort()
2020-03-10 18:02:10 +01:00
/* We don't handle this */
abort();
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
}
shm: add shm_did_not_use_buffer() This allows a caller to return a buffer (obtained with shm_get_buffer()) to the pool, The buffer must not have been used. I.e. it must not have been attached and committed to a wayland surface.
2022-04-16 17:47:56 +02:00
void
shm_did_not_use_buf(struct buffer *_buf)
{
struct buffer_private *buf = (struct buffer_private *)_buf;
buf->busy = false;
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
void
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
shm_get_many(struct buffer_chain *chain, size_t count,
int widths[static count], int heights[static count],
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
struct buffer *bufs[static count], bool with_alpha)
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
{
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
get_new_buffers(chain, count, widths, heights, bufs, with_alpha, true);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
}
struct buffer *
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
shm_get_buffer(struct buffer_chain *chain, int width, int height, bool with_alpha)
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
{
shm: chain_free: BUG() if there are buffers remaining after purge There may be buffers left, if their destruction has been deferred. However, they should be on the 'deferred' list, not the chain's buffer list. If there are buffers left on the chain's list, that means someone forgot to call shm_unref().
2021-07-16 16:49:52 +02:00
LOG_DBG(
Codespell fixes
2023-10-03 14:12:58 +02:00
"chain=%p: looking for a reusable %dx%d buffer "
shm: chain_free: BUG() if there are buffers remaining after purge There may be buffers left, if their destruction has been deferred. However, they should be on the 'deferred' list, not the chain's buffer list. If there are buffers left on the chain's list, that means someone forgot to call shm_unref().
2021-07-16 16:49:52 +02:00
"among %zu potential buffers",
(void *)chain, width, height, tll_length(chain->bufs));
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
struct buffer_private *cached = NULL;
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
tll_foreach(chain->bufs, it) {
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
struct buffer_private *buf = it->item;
shm: discard shm buffers with mis-matching alpha-setting
2024-06-24 17:55:07 +02:00
if (buf->public.width != width || buf->public.height != height ||
with_alpha != buf->with_alpha)
{
shm: get_buffer: purge mismatching buffers in first buffer iteration There's no longer any need to defer purging of mismatching buffer (i.e. buffers whose width/height doesn't match the requested ones) to after the cache lookup loop.
2021-07-16 16:49:27 +02:00
LOG_DBG("purging mismatching buffer %p", (void *)buf);
if (buffer_unref_no_remove_from_chain(buf))
tll_remove(chain->bufs, it);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
continue;
shm: get_buffer: purge mismatching buffers in first buffer iteration There's no longer any need to defer purging of mismatching buffer (i.e. buffers whose width/height doesn't match the requested ones) to after the cache lookup loop.
2021-07-16 16:49:27 +02:00
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
if (buf->busy)
buf->public.age++;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
else
#if FORCED_DOUBLE_BUFFERING
shm: fix compilation when FORCED_DOUBLE_BUFFERING is enabled
2024-09-20 17:06:47 +02:00
if (buf->public.age == 0)
buf->public.age++;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
else
#endif
{
shm: revert part of 299186a6547f6e038ee6f3822caf9a0fdfabceef 299186a6547f6e038ee6f3822caf9a0fdfabceef introduced a regression, where we don't handle SHM buffer "hiccups" correctly. If foot, for some reason is forced to render a frame "too soon", we might end up having multiple buffers "in flight" (i.e. committed to the compositor). This could happen if the compositor pushes multiple configure events rapidly, for example. Or anything else that forces foot to render something "immediately", without waiting for a frame callback. The compositor typically releases both buffers at the same time (or close to it), so the _next_ time we want to render a frame, we have *two* buffers to pick between. The problem here is that after 299186a6547f6e038ee6f3822caf9a0fdfabceef, foot no longer purges the additional buffer(s), but keeps all of them around. This messes up foot's age tracking, and the _next_ time we're forced to pull two buffers (without the compositor releasing the first one in between), we try to apply damage tracking that is no longer valid. This results in visual glitches. This never self-repairs, and we're stuck with visual glitches until the window is resized, and we're forced to allocate completely new buffers. It is unclear why 299186a6547f6e038ee6f3822caf9a0fdfabceef stopped removing the buffers. It was likely done early in the development, and is no longer needed. So far, I haven't noticed any bugs by re-introducing the buffer purging, but further testing is needed.
2025-12-16 14:56:42 +01:00
if (cached == NULL) {
shm: get_buffer(): make sure buffer->busy is set When going through the cached buffers, we only set buffer->busy on the *first* re-usable buffer we found. In some cases, we will find more than one re-usable buffer. In this case, we select the “youngest” one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer). If the “current” buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one. But, we did not sanitize it. That is, we did not: * set buffer->busy * clear its dirty region * clear its scroll damage That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would free it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail. Closes #844
2021-12-15 12:37:21 +01:00
cached = buf;
shm: revert part of 299186a6547f6e038ee6f3822caf9a0fdfabceef 299186a6547f6e038ee6f3822caf9a0fdfabceef introduced a regression, where we don't handle SHM buffer "hiccups" correctly. If foot, for some reason is forced to render a frame "too soon", we might end up having multiple buffers "in flight" (i.e. committed to the compositor). This could happen if the compositor pushes multiple configure events rapidly, for example. Or anything else that forces foot to render something "immediately", without waiting for a frame callback. The compositor typically releases both buffers at the same time (or close to it), so the _next_ time we want to render a frame, we have *two* buffers to pick between. The problem here is that after 299186a6547f6e038ee6f3822caf9a0fdfabceef, foot no longer purges the additional buffer(s), but keeps all of them around. This messes up foot's age tracking, and the _next_ time we're forced to pull two buffers (without the compositor releasing the first one in between), we try to apply damage tracking that is no longer valid. This results in visual glitches. This never self-repairs, and we're stuck with visual glitches until the window is resized, and we're forced to allocate completely new buffers. It is unclear why 299186a6547f6e038ee6f3822caf9a0fdfabceef stopped removing the buffers. It was likely done early in the development, and is no longer needed. So far, I haven't noticed any bugs by re-introducing the buffer purging, but further testing is needed.
2025-12-16 14:56:42 +01:00
} else {
shm: codespell
2021-07-15 19:40:15 +02:00
/* We have multiple buffers eligible for
Don't use fancy Unicode quotes, stick to ASCII
2024-02-06 12:36:45 +01:00
* reuse. Pick the "youngest" one, and mark the
shm: auto-purge when we have multiple buffers eligible for re-use It may happen that we end up with multiple non-busy, same-sized buffers for the same cookie (context), and thus eligible for re-use. Before this patch, we would keep all those buffers around. This is completely unnecessary. Under normal circumstances, we’ll either be re-using a single buffer, or swap between two. In the second case, the “other” buffer is always busy, and thus not eligible for re-use. So, if we _do_ detect multiple, re-usable buffers, pick the one with the lowest “age” (increasing the chance of applying damage tracking, instead of re-drawing everything), and mark the other one for purging.
2021-07-15 19:19:31 +02:00
* other one for purging */
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
if (buf->public.age < cached->public.age) {
shm: revert part of 299186a6547f6e038ee6f3822caf9a0fdfabceef 299186a6547f6e038ee6f3822caf9a0fdfabceef introduced a regression, where we don't handle SHM buffer "hiccups" correctly. If foot, for some reason is forced to render a frame "too soon", we might end up having multiple buffers "in flight" (i.e. committed to the compositor). This could happen if the compositor pushes multiple configure events rapidly, for example. Or anything else that forces foot to render something "immediately", without waiting for a frame callback. The compositor typically releases both buffers at the same time (or close to it), so the _next_ time we want to render a frame, we have *two* buffers to pick between. The problem here is that after 299186a6547f6e038ee6f3822caf9a0fdfabceef, foot no longer purges the additional buffer(s), but keeps all of them around. This messes up foot's age tracking, and the _next_ time we're forced to pull two buffers (without the compositor releasing the first one in between), we try to apply damage tracking that is no longer valid. This results in visual glitches. This never self-repairs, and we're stuck with visual glitches until the window is resized, and we're forced to allocate completely new buffers. It is unclear why 299186a6547f6e038ee6f3822caf9a0fdfabceef stopped removing the buffers. It was likely done early in the development, and is no longer needed. So far, I haven't noticed any bugs by re-introducing the buffer purging, but further testing is needed.
2025-12-16 14:56:42 +01:00
shm_unref(&cached->public);
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
cached = buf;
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
} else {
shm: get_buffer(): make sure buffer->busy is set When going through the cached buffers, we only set buffer->busy on the *first* re-usable buffer we found. In some cases, we will find more than one re-usable buffer. In this case, we select the “youngest” one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer). If the “current” buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one. But, we did not sanitize it. That is, we did not: * set buffer->busy * clear its dirty region * clear its scroll damage That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would free it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail. Closes #844
2021-12-15 12:37:21 +01:00
/*
* TODO: I think we _can_ use shm_unref()
* here...
*
Don't use fancy Unicode quotes, stick to ASCII
2024-02-06 12:36:45 +01:00
* shm_unref() may remove 'it', but that
* should be safe; "our" tll_foreach() already
shm: get_buffer(): make sure buffer->busy is set When going through the cached buffers, we only set buffer->busy on the *first* re-usable buffer we found. In some cases, we will find more than one re-usable buffer. In this case, we select the “youngest” one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer). If the “current” buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one. But, we did not sanitize it. That is, we did not: * set buffer->busy * clear its dirty region * clear its scroll damage That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would free it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail. Closes #844
2021-12-15 12:37:21 +01:00
* holds the next pointer.
*/
shm: revert part of 299186a6547f6e038ee6f3822caf9a0fdfabceef 299186a6547f6e038ee6f3822caf9a0fdfabceef introduced a regression, where we don't handle SHM buffer "hiccups" correctly. If foot, for some reason is forced to render a frame "too soon", we might end up having multiple buffers "in flight" (i.e. committed to the compositor). This could happen if the compositor pushes multiple configure events rapidly, for example. Or anything else that forces foot to render something "immediately", without waiting for a frame callback. The compositor typically releases both buffers at the same time (or close to it), so the _next_ time we want to render a frame, we have *two* buffers to pick between. The problem here is that after 299186a6547f6e038ee6f3822caf9a0fdfabceef, foot no longer purges the additional buffer(s), but keeps all of them around. This messes up foot's age tracking, and the _next_ time we're forced to pull two buffers (without the compositor releasing the first one in between), we try to apply damage tracking that is no longer valid. This results in visual glitches. This never self-repairs, and we're stuck with visual glitches until the window is resized, and we're forced to allocate completely new buffers. It is unclear why 299186a6547f6e038ee6f3822caf9a0fdfabceef stopped removing the buffers. It was likely done early in the development, and is no longer needed. So far, I haven't noticed any bugs by re-introducing the buffer purging, but further testing is needed.
2025-12-16 14:56:42 +01:00
if (buffer_unref_no_remove_from_chain(buf))
tll_remove(chain->bufs, it);
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
}
}
}
shm: get_buffer(): make sure buffer->busy is set When going through the cached buffers, we only set buffer->busy on the *first* re-usable buffer we found. In some cases, we will find more than one re-usable buffer. In this case, we select the “youngest” one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer). If the “current” buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one. But, we did not sanitize it. That is, we did not: * set buffer->busy * clear its dirty region * clear its scroll damage That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would free it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail. Closes #844
2021-12-15 12:37:21 +01:00
if (cached != NULL) {
shm: codespell: re-using -> reusing
2025-01-22 07:50:49 +01:00
LOG_DBG("reusing buffer %p from cache", (void *)cached);
shm: get_buffer(): make sure buffer->busy is set When going through the cached buffers, we only set buffer->busy on the *first* re-usable buffer we found. In some cases, we will find more than one re-usable buffer. In this case, we select the “youngest” one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer). If the “current” buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one. But, we did not sanitize it. That is, we did not: * set buffer->busy * clear its dirty region * clear its scroll damage That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would free it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail. Closes #844
2021-12-15 12:37:21 +01:00
cached->busy = true;
render: more fine-grained wayland surface damage tracking Before this patch. Wayland surface damage tracking was done on a per-row basis. That is, even if just one cell was updated, the entire row was "damaged". Now, damage is per cell. This hopefully results in lower latencies in many use cases, and especially on high DPI monitors.
2023-10-07 16:23:09 +02:00
for (size_t i = 0; i < cached->public.pix_instances; i++)
pixman_region32_clear(&cached->public.dirty[i]);
shm: get_buffer(): make sure buffer->busy is set When going through the cached buffers, we only set buffer->busy on the *first* re-usable buffer we found. In some cases, we will find more than one re-usable buffer. In this case, we select the “youngest” one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer). If the “current” buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one. But, we did not sanitize it. That is, we did not: * set buffer->busy * clear its dirty region * clear its scroll damage That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would free it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail. Closes #844
2021-12-15 12:37:21 +01:00
xassert(cached->public.pix_instances == chain->pix_instances);
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
return &cached->public;
shm: get_buffer(): make sure buffer->busy is set When going through the cached buffers, we only set buffer->busy on the *first* re-usable buffer we found. In some cases, we will find more than one re-usable buffer. In this case, we select the “youngest” one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer). If the “current” buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one. But, we did not sanitize it. That is, we did not: * set buffer->busy * clear its dirty region * clear its scroll damage That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would free it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail. Closes #844
2021-12-15 12:37:21 +01:00
}
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
struct buffer *ret;
shm: use XRGB surfaces when we know we wont be using transparency
2024-02-21 16:29:10 +01:00
get_new_buffers(chain, 1, &width, &height, &ret, with_alpha, false);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
return ret;
initial commit: maps an XDG toplevel window
2019-06-12 20:08:54 +02:00
}
shm: add shm_can_scroll()
2020-03-23 19:31:05 +01:00
bool
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm_can_scroll(const struct buffer *_buf)
shm: add shm_can_scroll()
2020-03-23 19:31:05 +01:00
{
shm: don’t check for __i386__ and __x86_64__ - there are other architectures out there Instead, check for __SIZEOF_POINTER__ == 8, since what we’re really interested in is whether we have enough virtual address space or not.
2021-01-21 12:39:51 +01:00
#if __SIZEOF_POINTER__ == 8
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
const struct buffer_private *buf = (const struct buffer_private *)_buf;
shm: don’t check for __i386__ and __x86_64__ - there are other architectures out there Instead, check for __SIZEOF_POINTER__ == 8, since what we’re really interested in is whether we have enough virtual address space or not.
2021-01-21 12:39:51 +01:00
return can_punch_hole && max_pool_size > 0 && buf->scrollable;
#else
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
/* Not enough virtual address space in 32-bit */
return false;
#endif
}
shm: don’t check for __i386__ and __x86_64__ - there are other architectures out there Instead, check for __SIZEOF_POINTER__ == 8, since what we’re really interested in is whether we have enough virtual address space or not.
2021-01-21 12:39:51 +01:00
#if __SIZEOF_POINTER__ == 8 && defined(FALLOC_FL_PUNCH_HOLE)
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
static bool
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
wrap_buffer(struct buffer_private *buf, off_t new_offset)
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
{
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
struct buffer_pool *pool = buf->pool;
xassert(pool->ref_count == 1);
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
/* We don't allow overlapping offsets */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
off_t UNUSED diff = new_offset < buf->offset
? buf->offset - new_offset
: new_offset - buf->offset;
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
xassert(diff > buf->size);
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
memcpy((uint8_t *)pool->real_mmapped + new_offset,
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
buf->public.data,
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
buf->size);
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
off_t trim_ofs, trim_len;
if (new_offset > buf->offset) {
/* Trim everything *before* the new offset */
trim_ofs = 0;
trim_len = new_offset;
} else {
/* Trim everything *after* the new buffer location */
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
trim_ofs = new_offset + buf->size;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
trim_len = pool->mmap_size - trim_ofs;
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
}
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
if (fallocate(
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
pool->fd,
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
trim_ofs, trim_len) < 0)
{
LOG_ERRNO("failed to trim SHM backing memory file");
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
return false;
}
/* Re-instantiate pixman+wl_buffer+raw pointersw */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
buffer_destroy_dont_close(&buf->public);
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
return instantiate_offset(buf, new_offset);
shm: add shm_can_scroll()
2020-03-23 19:31:05 +01:00
}
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
static bool
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
shm_scroll_forward(struct buffer_private *buf, int rows,
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
int top_margin, int top_keep_rows,
int bottom_margin, int bottom_keep_rows)
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
{
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
struct buffer_pool *pool = buf->pool;
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(can_punch_hole);
xassert(buf->busy);
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
xassert(buf->public.pix != NULL);
xassert(buf->public.wl_buf != NULL);
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
xassert(pool != NULL);
xassert(pool->ref_count == 1);
xassert(pool->fd >= 0);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
shm: we may exit with busy buffers remaining (seen on KDE)
2021-07-16 16:47:15 +02:00
LOG_DBG("scrolling %d rows (%d bytes)", rows, rows * buf->public.stride);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
const off_t diff = rows * buf->public.stride;
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(rows > 0);
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
xassert(diff < buf->size);
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
if (buf->offset + diff + buf->size > max_pool_size) {
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
LOG_DBG("memfd offset wrap around");
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
if (!wrap_buffer(buf, 0))
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
goto err;
}
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
off_t new_offset = buf->offset + diff;
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(new_offset > buf->offset);
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
xassert(new_offset + buf->size <= max_pool_size);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec tot;
struct timespec time1;
clock_gettime(CLOCK_MONOTONIC, &time1);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time2 = time1;
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
#endif
if (top_keep_rows > 0) {
/* Copy current 'top' region to its new location */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
const int stride = buf->public.stride;
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
uint8_t *base = buf->public.data;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
memmove(
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
base + (top_margin + rows) * stride,
base + (top_margin + 0) * stride,
top_keep_rows * stride);
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
clock_gettime(CLOCK_MONOTONIC, &time2);
timespec_sub(&time2, &time1, &tot);
LOG_INFO("memmove (top region): %lds %ldns",
(long)tot.tv_sec, tot.tv_nsec);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
#endif
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
}
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
/* Destroy old objects (they point to the old offset) */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
buffer_destroy_dont_close(&buf->public);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
/* Free unused memory - everything up until the new offset */
const off_t trim_ofs = 0;
const off_t trim_len = new_offset;
if (fallocate(
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
pool->fd,
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
trim_ofs, trim_len) < 0)
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
{
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
LOG_ERRNO("failed to trim SHM backing memory file");
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
goto err;
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
}
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time3;
clock_gettime(CLOCK_MONOTONIC, &time3);
timespec_sub(&time3, &time2, &tot);
LOG_INFO("PUNCH HOLE: %lds %ldns", (long)tot.tv_sec, tot.tv_nsec);
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
#endif
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
/* Re-instantiate pixman+wl_buffer+raw pointersw */
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
bool ret = instantiate_offset(buf, new_offset);
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time4;
clock_gettime(CLOCK_MONOTONIC, &time4);
timespec_sub(&time4, &time3, &tot);
LOG_INFO("instantiate offset: %lds %ldns", (long)tot.tv_sec, tot.tv_nsec);
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
#endif
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
if (ret && bottom_keep_rows > 0) {
/* Copy 'bottom' region to its new location */
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
const size_t size = buf->size;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
const int stride = buf->public.stride;
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
uint8_t *base = buf->public.data;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
memmove(
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
base + size - (bottom_margin + bottom_keep_rows) * stride,
base + size - (bottom_margin + rows + bottom_keep_rows) * stride,
bottom_keep_rows * stride);
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time5;
clock_gettime(CLOCK_MONOTONIC, &time5);
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
timespec_sub(&time5, &time4, &tot);
LOG_INFO("memmove (bottom region): %lds %ldns",
(long)tot.tv_sec, tot.tv_nsec);
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
#endif
}
return ret;
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
err:
abort();
return false;
shm: new function, shm_scroll() 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).
2020-03-22 20:06:44 +01:00
}
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
static bool
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
shm_scroll_reverse(struct buffer_private *buf, int rows,
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
int top_margin, int top_keep_rows,
int bottom_margin, int bottom_keep_rows)
{
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(rows > 0);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
struct buffer_pool *pool = buf->pool;
xassert(pool->ref_count == 1);
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
const off_t diff = rows * buf->public.stride;
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
if (diff > buf->offset) {
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
LOG_DBG("memfd offset reverse wrap-around");
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
if (!wrap_buffer(buf, (max_pool_size - buf->size) & ~(page_size() - 1)))
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
goto err;
}
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
off_t new_offset = buf->offset - diff;
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(new_offset < buf->offset);
xassert(new_offset <= max_pool_size);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time0;
clock_gettime(CLOCK_MONOTONIC, &time0);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec tot;
struct timespec time1 = time0;
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
#endif
if (bottom_keep_rows > 0) {
/* Copy 'bottom' region to its new location */
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
const size_t size = buf->size;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
const int stride = buf->public.stride;
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
uint8_t *base = buf->public.data;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
memmove(
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
base + size - (bottom_margin + rows + bottom_keep_rows) * stride,
base + size - (bottom_margin + bottom_keep_rows) * stride,
bottom_keep_rows * stride);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
clock_gettime(CLOCK_MONOTONIC, &time1);
timespec_sub(&time1, &time0, &tot);
LOG_INFO("memmove (bottom region): %lds %ldns",
(long)tot.tv_sec, tot.tv_nsec);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
#endif
}
/* Destroy old objects (they point to the old offset) */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
buffer_destroy_dont_close(&buf->public);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
/* Free unused memory - everything after the relocated buffer */
shm: move ‘size’ to the private buffer struct
2021-07-15 22:30:08 +02:00
const off_t trim_ofs = new_offset + buf->size;
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
const off_t trim_len = pool->mmap_size - trim_ofs;
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
if (fallocate(
shm: add shm_get_many() - allows buffers to share a single pool shm_get_many() always returns new buffers (i.e. never old, cached ones). The newly allocated buffers are also marked for immediate purging, meaning they’ll be destroyed on the next call to either shm_get_buffer(), or shm_get_many(). Furthermore, we add a new attribute, ‘locked’, to the buffer struct. When auto purging buffers, look at this instead of comparing cookies. Buffer consumers are expected to set ‘locked’ while they hold a reference to it, and don’t want it destroyed behind their back.
2021-07-15 18:32:19 +02:00
pool->fd,
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
trim_ofs, trim_len) < 0)
{
LOG_ERRNO("failed to trim SHM backing memory");
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
goto err;
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
}
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time2;
clock_gettime(CLOCK_MONOTONIC, &time2);
timespec_sub(&time2, &time1, &tot);
LOG_INFO("fallocate: %lds %ldns", (long)tot.tv_sec, tot.tv_nsec);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
#endif
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
/* Re-instantiate pixman+wl_buffer+raw pointers */
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
bool ret = instantiate_offset(buf, new_offset);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time3;
clock_gettime(CLOCK_MONOTONIC, &time3);
timespec_sub(&time3, &time2, &tot);
LOG_INFO("instantiate offset: %lds %ldns", (long)tot.tv_sec, tot.tv_nsec);
shm: scroll: keep shm pool around, and fix its size at max allowed 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.
2020-03-25 18:26:58 +01:00
#endif
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
if (ret && top_keep_rows > 0) {
/* Copy current 'top' region to its new location */
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
const int stride = buf->public.stride;
shm: rename buffer.mmapped to buffer.data
2021-07-15 22:18:09 +02:00
uint8_t *base = buf->public.data;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
memmove(
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
base + (top_margin + 0) * stride,
base + (top_margin + rows) * stride,
top_keep_rows * stride);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
#if TIME_SCROLL
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
struct timespec time4;
clock_gettime(CLOCK_MONOTONIC, &time4);
timespec_sub(&time4, &time3, &tot);
LOG_INFO("memmove (top region): %lds %ldns",
(long)tot.tv_sec, tot.tv_nsec);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
#endif
}
return ret;
shm: scroll: implement offset wrap-around * 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.
2020-03-24 17:46:48 +01:00
err:
abort();
return false;
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
}
shm: disable fallocate optimization if not supported shm.c:301:26: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] can_punch_hole = fallocate( ^ shm.c:302:22: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' pool_fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 0, 1) == 0; ^ shm.c:302:45: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' pool_fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 0, 1) == 0; ^ shm.c:432:9: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (fallocate( ^ shm.c:434:13: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:434:36: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:501:9: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (fallocate( ^ shm.c:503:13: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:503:36: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:597:9: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (fallocate( ^ shm.c:599:13: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:599:36: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^
2021-01-19 15:22:51 +00:00
#endif /* FALLOC_FL_PUNCH_HOLE */
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
bool
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
shm_scroll(struct buffer *_buf, int rows,
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
int top_margin, int top_keep_rows,
int bottom_margin, int bottom_keep_rows)
{
shm: don’t check for __i386__ and __x86_64__ - there are other architectures out there Instead, check for __SIZEOF_POINTER__ == 8, since what we’re really interested in is whether we have enough virtual address space or not.
2021-01-21 12:39:51 +01:00
#if __SIZEOF_POINTER__ == 8 && defined(FALLOC_FL_PUNCH_HOLE)
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
if (!shm_can_scroll(_buf))
conf: max-shm-pool-size-mb=0 now disables SHM scrolling
2020-03-26 18:04:30 +01:00
return false;
shm: split up buffer struct into internal/private and public parts
2021-07-15 22:17:12 +02:00
struct buffer_private *buf = (struct buffer_private *)_buf;
debug: rename assert() to xassert(), to avoid clashing with <assert.h>
2021-01-16 20:16:00 +00:00
xassert(rows != 0);
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
return rows > 0
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
? shm_scroll_forward(buf, rows, top_margin, top_keep_rows, bottom_margin, bottom_keep_rows)
: shm_scroll_reverse(buf, -rows, top_margin, top_keep_rows, bottom_margin, bottom_keep_rows);
shm: disable fallocate optimization if not supported shm.c:301:26: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] can_punch_hole = fallocate( ^ shm.c:302:22: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' pool_fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 0, 1) == 0; ^ shm.c:302:45: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' pool_fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 0, 1) == 0; ^ shm.c:432:9: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (fallocate( ^ shm.c:434:13: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:434:36: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:501:9: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (fallocate( ^ shm.c:503:13: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:503:36: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:597:9: error: implicit declaration of function 'fallocate' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (fallocate( ^ shm.c:599:13: error: use of undeclared identifier 'FALLOC_FL_PUNCH_HOLE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^ shm.c:599:36: error: use of undeclared identifier 'FALLOC_FL_KEEP_SIZE' FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, ^
2021-01-19 15:22:51 +00:00
#else
return false;
#endif
shm: shm_scroll(): initial implementation of reverse scrolling 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).
2020-03-23 21:14:51 +01:00
}
shm: fix badly indented function return type
2020-12-04 18:42:16 +01:00
void
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
shm_purge(struct buffer_chain *chain)
shm: add shm_purge() Destroys *all* buffers associated with the specified cookie.
2019-11-02 00:49:00 +01:00
{
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
LOG_DBG("chain: %p: purging all buffers", (void *)chain);
shm: add shm_purge() Destroys *all* buffers associated with the specified cookie.
2019-11-02 00:49:00 +01:00
/* Purge old buffers associated with this cookie */
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
tll_foreach(chain->bufs, it) {
if (buffer_unref_no_remove_from_chain(it->item))
tll_remove(chain->bufs, it);
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
}
}
void
shm_addref(struct buffer *_buf)
{
struct buffer_private *buf = (struct buffer_private *)_buf;
buf->ref_count++;
}
void
shm_unref(struct buffer *_buf)
{
if (_buf == NULL)
return;
struct buffer_private *buf = (struct buffer_private *)_buf;
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
struct buffer_chain *chain = buf->chain;
tll_foreach(chain->bufs, it) {
shm: remove deferred buffers from main list immediately When unref:ing a "busy" buffer, destruction is (still) deferred to the buffer release event. However, we now move the buffer off the buffer list immediately, and instead push it to a 'deferred' list. This prevents buffer re-use of buffers scheduled for destruction. It also means less buffers to iterate through when trying to find a re-usable buffer in shm_get_buffer(), since we no longer have to wade through a potentially long list of to-be-deleted buffers.
2021-07-16 16:48:18 +02:00
if (it->item != buf)
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
continue;
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
if (buffer_unref_no_remove_from_chain(buf))
tll_remove(chain->bufs, it);
shm: replace 'locked' attribute with a ref-counter The initial ref-count is either 1 or 0, depending on whether the buffer is supposed to be released "immeidately" (meaning, as soon as the compositor releases it). Two new user facing functions have been added: shm_addref() and shm_unref(). Our renderer now uses these two functions instead of manually setting and clearing the 'locked' attribute. shm_unref() will decrement the ref-counter, and destroy the buffer when the counter reaches zero. Except if the buffer is currently "busy" (compositor owned), in which case destruction is deferred to the release event. The buffer is still removed from the list though.
2021-07-16 16:47:57 +02:00
break;
shm: add shm_purge() Destroys *all* buffers associated with the specified cookie.
2019-11-02 00:49:00 +01:00
}
}
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
struct buffer_chain *
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
shm_chain_new(struct wayland *wayl, bool scrollable, size_t pix_instances,
render: when double-buffering, pre-apply previous frame's damage early Foot likes it when compositor releases buffer immediately, as that means we only have to re-render the cells that have changed since the last frame. For various reasons, not all compositors do this. In this case, foot is typically forced to switch between two buffers, i.e. double-buffer. In this case, each frame starts with copying over the damage from the previous frame, to the new frame. Then we start rendering the updated cells. Bringing over the previous frame's damage can be slow, if the changed area was large (e.g. when scrolling one or a few lines, or on full screen updates). It's also done single-threaded. Thus it not only slows down frame rendering, but pauses everything else (i.e. input processing). All in all, it reduces performance and increases input latency. But we don't have to wait until it's time to render a frame to copy over the previous frame's damage. We can do that as soon as the compositor has released the buffer (for the frame _before_ the previous frame). And we can do this in a thread. This frees up foot to continue processing input, and reduces frame rendering time since we can now start rendering the modified cells immediately, without first doing a large memcpy(3). In worst case scenarios (or perhaps we should consider them best case scenarios...), I've seen up to a 10x performance increase in frame rendering times (this obviously does *not* include the time it takes to copy over the previous frame's damage, since that doesn't affect neither input processing nor frame rendering). Implemented by adding a callback mechanism to the shm abstraction layer. Use it for the grid buffers, and kick off a thread that copies the previous frame's damage, and resets the buffers age to 0 (so that foot understands it can start render to it immediately when it later needs to render a frame). Since we have certain way of knowing if a compositor releases buffers immediately or not, use a bit of heuristics; if we see 10 consecutive non-immediate releases (that is, we reset the counter as soon as we do see an immediate release), this new "pre-apply damage" logic is enabled. It can be force-disabled with tweak.pre-apply-damage=no. We also need to take care to wait for the thread before resetting the render's "last_buf" pointer (or we'll SEGFAULT in the thread...). We must also ensure we wait for the thread to finish before we start rendering a new frame. Under normal circumstances, the wait time is always 0, the thread has almost always finished long before we need to render the next frame. But it _can_ happen. Closes #2188
2025-10-05 10:48:36 +02:00
enum shm_bit_depth desired_bit_depth,
void (*release_cb)(struct buffer *buf, void *data), void *cb_data)
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
{
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
pixman_format_code_t pixman_fmt_without_alpha = PIXMAN_x8r8g8b8;
enum wl_shm_format shm_fmt_without_alpha = WL_SHM_FORMAT_XRGB8888;
pixman_format_code_t pixman_fmt_with_alpha = PIXMAN_a8r8g8b8;
enum wl_shm_format shm_fmt_with_alpha = WL_SHM_FORMAT_ARGB8888;
static bool have_logged = false;
config: tweak.surface-bit-depth: add support for 16-bit surfaces This adds supports for 16-bit surfaces, using the new PIXMAN_a16b16g16r16 buffer format. This maps to WL_SHM_FORMAT_ABGR16161616 (little-endian). Use the new 16-bit surfaces by default, when gamma-correct-blending=yes.
2025-05-01 09:37:47 +02:00
static bool have_logged_10_fallback = false;
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
config: tweak.surface-bit-depth: add support for 16-bit surfaces This adds supports for 16-bit surfaces, using the new PIXMAN_a16b16g16r16 buffer format. This maps to WL_SHM_FORMAT_ABGR16161616 (little-endian). Use the new 16-bit surfaces by default, when gamma-correct-blending=yes.
2025-05-01 09:37:47 +02:00
#if defined(HAVE_PIXMAN_RGBA_16)
static bool have_logged_16_fallback = false;
if (desired_bit_depth == SHM_BITS_16) {
if (wayl->shm_have_abgr161616 && wayl->shm_have_xbgr161616) {
pixman_fmt_without_alpha = PIXMAN_a16b16g16r16;
shm_fmt_without_alpha = WL_SHM_FORMAT_XBGR16161616;
shm: don't set pixman_fmt_without_alpha twice When selecting 16-bit surfaces, we set pixman_fmt_without_alpha twice, and never set pixman_fmt_with_alpha. This caused 10-bit surfaces to be used instead, since it checks if pixman_fmt_with_alpha has been overridden or not.
2025-07-21 13:49:57 +02:00
pixman_fmt_with_alpha = PIXMAN_a16b16g16r16;
config: tweak.surface-bit-depth: add support for 16-bit surfaces This adds supports for 16-bit surfaces, using the new PIXMAN_a16b16g16r16 buffer format. This maps to WL_SHM_FORMAT_ABGR16161616 (little-endian). Use the new 16-bit surfaces by default, when gamma-correct-blending=yes.
2025-05-01 09:37:47 +02:00
shm_fmt_with_alpha = WL_SHM_FORMAT_ABGR16161616;
if (!have_logged) {
have_logged = true;
LOG_INFO("using 16-bit BGR surfaces");
}
} else {
if (!have_logged_16_fallback) {
have_logged_16_fallback = true;
LOG_WARN(
"16-bit surfaces requested, but compositor does not "
"implement ABGR161616+XBGR161616");
}
}
}
#endif
if (desired_bit_depth >= SHM_BITS_10 &&
pixman_fmt_with_alpha == PIXMAN_a8r8g8b8)
{
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
if (wayl->shm_have_argb2101010 && wayl->shm_have_xrgb2101010) {
pixman_fmt_without_alpha = PIXMAN_x2r10g10b10;
shm_fmt_without_alpha = WL_SHM_FORMAT_XRGB2101010;
pixman_fmt_with_alpha = PIXMAN_a2r10g10b10;
shm_fmt_with_alpha = WL_SHM_FORMAT_ARGB2101010;
if (!have_logged) {
have_logged = true;
LOG_INFO("using 10-bit RGB surfaces");
}
}
else if (wayl->shm_have_abgr2101010 && wayl->shm_have_xbgr2101010) {
pixman_fmt_without_alpha = PIXMAN_x2b10g10r10;
shm_fmt_without_alpha = WL_SHM_FORMAT_XBGR2101010;
pixman_fmt_with_alpha = PIXMAN_a2b10g10r10;
shm_fmt_with_alpha = WL_SHM_FORMAT_ABGR2101010;
if (!have_logged) {
have_logged = true;
LOG_INFO("using 10-bit BGR surfaces");
}
}
else {
config: tweak.surface-bit-depth: add support for 16-bit surfaces This adds supports for 16-bit surfaces, using the new PIXMAN_a16b16g16r16 buffer format. This maps to WL_SHM_FORMAT_ABGR16161616 (little-endian). Use the new 16-bit surfaces by default, when gamma-correct-blending=yes.
2025-05-01 09:37:47 +02:00
if (!have_logged_10_fallback) {
have_logged_10_fallback = true;
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
LOG_WARN(
"10-bit surfaces requested, but compositor does not "
"implement ARGB2101010+XRGB2101010, or "
config: tweak.surface-bit-depth: add support for 16-bit surfaces This adds supports for 16-bit surfaces, using the new PIXMAN_a16b16g16r16 buffer format. This maps to WL_SHM_FORMAT_ABGR16161616 (little-endian). Use the new 16-bit surfaces by default, when gamma-correct-blending=yes.
2025-05-01 09:37:47 +02:00
"ABGR2101010+XBGR2101010");
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
}
}
} else {
if (!have_logged) {
have_logged = true;
LOG_INFO("using 8-bit RGB surfaces");
}
}
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
struct buffer_chain *chain = xmalloc(sizeof(*chain));
*chain = (struct buffer_chain){
.bufs = tll_init(),
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
.shm = wayl->shm,
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
.pix_instances = pix_instances,
.scrollable = scrollable,
render: gamma-correct blending This implements gamma-correct blending, which mainly affects font rendering. The implementation requires compile-time availability of the new color-management protocol (available in wayland-protocols >= 1.41), and run-time support for the same in the compositor (specifically, the EXT_LINEAR TF function and sRGB primaries). How it works: all colors are decoded from sRGB to linear (using a lookup table, generated in the exact same way pixman generates it's internal conversion tables) before being used by pixman. The resulting image buffer is thus in decoded/linear format. We use the color-management protocol to inform the compositor of this, by tagging the wayland surfaces with the 'ext_linear' image attribute. Sixes: all colors are sRGB internally, and decoded to linear before being used in any sixels. Thus, the image buffers will contain linear colors. This is important, since otherwise there would be a decode/encode penalty every time a sixel is blended to the grid. Emojis: we require fcft >= 3.2, which adds support for sRGB decoding color glyphs. Meaning, the emoji pixman surfaces can be blended directly to the grid, just like sixels. Gamma-correct blending is enabled by default *when the compositor supports it*. There's a new option to explicitly enable/disable it: gamma-correct-blending=no|yes. If set to 'yes', and the compositor does not implement the required color-management features, warning logs are emitted. There's a loss of precision when storing linear pixels in 8-bit channels. For this reason, this patch also adds supports for 10-bit surfaces. For now, this is disabled by default since such surfaces only have 2 bits for alpha. It can be enabled with tweak.surface-bit-depth=10-bit. Perhaps, in the future, we can enable it by default if: * gamma-correct blending is enabled * the user has not enabled a transparent background
2025-02-21 11:01:29 +01:00
.pixman_fmt_without_alpha = pixman_fmt_without_alpha,
.shm_format_without_alpha = shm_fmt_without_alpha,
.pixman_fmt_with_alpha = pixman_fmt_with_alpha,
.shm_format_with_alpha = shm_fmt_with_alpha,
render: when double-buffering, pre-apply previous frame's damage early Foot likes it when compositor releases buffer immediately, as that means we only have to re-render the cells that have changed since the last frame. For various reasons, not all compositors do this. In this case, foot is typically forced to switch between two buffers, i.e. double-buffer. In this case, each frame starts with copying over the damage from the previous frame, to the new frame. Then we start rendering the updated cells. Bringing over the previous frame's damage can be slow, if the changed area was large (e.g. when scrolling one or a few lines, or on full screen updates). It's also done single-threaded. Thus it not only slows down frame rendering, but pauses everything else (i.e. input processing). All in all, it reduces performance and increases input latency. But we don't have to wait until it's time to render a frame to copy over the previous frame's damage. We can do that as soon as the compositor has released the buffer (for the frame _before_ the previous frame). And we can do this in a thread. This frees up foot to continue processing input, and reduces frame rendering time since we can now start rendering the modified cells immediately, without first doing a large memcpy(3). In worst case scenarios (or perhaps we should consider them best case scenarios...), I've seen up to a 10x performance increase in frame rendering times (this obviously does *not* include the time it takes to copy over the previous frame's damage, since that doesn't affect neither input processing nor frame rendering). Implemented by adding a callback mechanism to the shm abstraction layer. Use it for the grid buffers, and kick off a thread that copies the previous frame's damage, and resets the buffers age to 0 (so that foot understands it can start render to it immediately when it later needs to render a frame). Since we have certain way of knowing if a compositor releases buffers immediately or not, use a bit of heuristics; if we see 10 consecutive non-immediate releases (that is, we reset the counter as soon as we do see an immediate release), this new "pre-apply damage" logic is enabled. It can be force-disabled with tweak.pre-apply-damage=no. We also need to take care to wait for the thread before resetting the render's "last_buf" pointer (or we'll SEGFAULT in the thread...). We must also ensure we wait for the thread to finish before we start rendering a new frame. Under normal circumstances, the wait time is always 0, the thread has almost always finished long before we need to render the next frame. But it _can_ happen. Closes #2188
2025-10-05 10:48:36 +02:00
.release_cb = release_cb,
.cb_data = cb_data,
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
};
return chain;
}
void
shm_chain_free(struct buffer_chain *chain)
{
if (chain == NULL)
return;
shm: get_buffer: purge mismatching buffers in first buffer iteration There's no longer any need to defer purging of mismatching buffer (i.e. buffers whose width/height doesn't match the requested ones) to after the cache lookup loop.
2021-07-16 16:49:27 +02:00
shm_purge(chain);
shm: chain_free: BUG() if there are buffers remaining after purge There may be buffers left, if their destruction has been deferred. However, they should be on the 'deferred' list, not the chain's buffer list. If there are buffers left on the chain's list, that means someone forgot to call shm_unref().
2021-07-16 16:49:52 +02:00
if (tll_length(chain->bufs) > 0) {
BUG("chain=%p: there are buffers remaining; "
"is there a missing call to shm_unref()?", (void *)chain);
}
shm: refactor: move away from a single, global, buffer list Up until now, *all* buffers have been tracked in a single, global buffer list. We've used 'cookies' to separate buffers from different contexts (so that shm_get_buffer() doesn't try to re-use e.g. a search-box buffer for the main grid). This patch refactors this, and completely removes the global list. Instead of cookies, we now use 'chains'. A chain tracks both the properties to apply to newly created buffers (scrollable, number of pixman instances to instantiate etc), as well as the instantiated buffers themselves. This means there's strictly speaking not much use for shm_fini() anymore, since its up to the chain owner to call shm_chain_free(), which will also purge all buffers. However, since purging a buffer may be deferred, if the buffer is owned by the compositor at the time of the call to shm_purge() or shm_chain_free(), we still keep a global 'deferred' list, on to which deferred buffers are pushed. shm_fini() iterates this list and destroys the buffers _even_ if they are still owned by the compositor. This only happens at program termination, and not when destroying a terminal instance. I.e. closing a window in a “foot --server” does *not* trigger this. Each terminal instatiates a number of chains, and these chains are destroyed when the terminal instance is destroyed. Note that some buffers may be put on the deferred list, as mentioned above.
2021-07-16 16:48:49 +02:00
free(chain);
}
config: tweak.surface-bit-depth now defaults to 'auto' When set to 'auto', use 10-bit surfaces if gamma-correct blending is enabled, and 8-bit surfaces otherwise. Note that we may still fallback to 8-bit surfaces (without disabling gamma-correct blending) if the compositor does not support 10-bit surfaces. Closes #2082
2025-05-01 08:34:49 +02:00
enum shm_bit_depth
shm_chain_bit_depth(const struct buffer_chain *chain)
{
const pixman_format_code_t fmt = chain->pixman_fmt_with_alpha;
config: tweak.surface-bit-depth: add support for 16-bit surfaces This adds supports for 16-bit surfaces, using the new PIXMAN_a16b16g16r16 buffer format. This maps to WL_SHM_FORMAT_ABGR16161616 (little-endian). Use the new 16-bit surfaces by default, when gamma-correct-blending=yes.
2025-05-01 09:37:47 +02:00
return fmt == PIXMAN_a8r8g8b8
? SHM_BITS_8
#if defined(HAVE_PIXMAN_RGBA_16)
: fmt == PIXMAN_a16b16g16r16
? SHM_BITS_16
#endif
: SHM_BITS_10;
config: tweak.surface-bit-depth now defaults to 'auto' When set to 'auto', use 10-bit surfaces if gamma-correct blending is enabled, and 8-bit surfaces otherwise. Note that we may still fallback to 8-bit surfaces (without disabling gamma-correct blending) if the compositor does not support 10-bit surfaces. Closes #2082
2025-05-01 08:34:49 +02:00
}
Reference in a new issue Copy permalink