This is needed, since we disable alpha in fullscreen, and since we use
different image buffer formats (XRGB vs. ARGB) when we have alpha
vs. when we don't (and fullscreen always disables alpha).
Normally, this happens anyway, as the window is resized when going in
or out from fullscreen. But, it's technically possible for a
compositor to change an application's fullscreen state without
resizing the window.
This fixes an off by one, where we sometimes "ate" an extra space when
extracting contents with tabs. This happened if the tab (and its
subsequent spaces) were followed by an additional space.
Closes#2194
Before this patch, we always blended towards black when dimming
text. However, with light color themes, it usually looks better if we
dim towards white instead.
This option allows you to choose which color to blend towards.
The default is 'black' in '[colors]', and 'white' in '[colors2]'.
Closes#2187
When exiting fullscreen mode, the window's transparency was not being
restored, leaving it opaque until another window was fullscreened.
This occurred because the Wayland opaque region was set based only on
the configured alpha value, without considering the fullscreen state.
Since commit
899b768b74 ("render: disable transparency when we're fullscreened")
transparency is disabled during fullscreen to avoid
compositor-mandated black backgrounds affecting the intended colors.
However, the opaque region was not being updated when the fullscreen
state changed.
Fixes: https://codeberg.org/dnkl/foot/issues/2180
Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net>
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
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
When we print a character to the grid, we must also update its OSC-8
state if an OSC-8 URI is currently active.
For double-width characters, this was only being done for the first
cell.
This causes the labels in URL mode to be off, as the link was
effectively chopped up into multiple pieces.
Closes#2179
This makes the "uppercase hint character inserts selected text"
behavior added in #1975 configurable, as it can have unexpected
behavior for some users.
It defaults to "on", preserving the new behavior of `foot`, after
Fixes#2159.
Some of the value_to_*() functions wrote directly to the output
variable, even when the value was invalid. This often resulted in the
an actual configuration option (i.e. a member in the config struct) to
be overwritten by an invalid value.
For example, -o initial-color-theme=0 would set
conf->initial_color_theme to -1, resulting in a crash later, when
initializing a terminal instance.
This patch adds the IPC infrastructure necessary to propagate
SIGUSR1/SIGUSR2 from a footclient process to the server process.
By targeting a particular footclient instance, only that particular
instance changes theme. This is different from when targeting the
server process, where all instances change theme.
Closes#2156
When sending SIGUSR1/SIGUSR2 to a server process, all currently
running client instances change their theme. But before this patch,
all future instances used the original theme. With this patch, the
server owned config object is updated with the selected theme, thus
making new instances use the same theme as well.
This ensures applications don't mistake foot for another terminal
emulator. Not that applications _should_ rely on environment
variables, but some do anyway...
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.
Before this patch, SIGUSR1 toggled between [colors] and
[colors2].
Now, SIGUSR1 changes to [colors], regardless of what the current color
theme is, and SIGUSR2 changes to [colors2].
Closes#2144
