run_command() was only run at configure time, meaning the generated
version (that was passed on to the sources via -DFUZZEL_VERSION)
became stale.
Fix by implementing a shell script that generates a header file, and
wrap this in a custom target that is run every time (but the generated
file is only updated when the version changes)
When instantiating a primary font, build the fallback font list, but
don't actually instantiate the fallback fonts.
Instead, remember the (full) pattern that we should use if/when we
instantiate it.
Then, when looking up a glyph and we need a fallback font, loop the
list and instantiate the font(s) there and then.
The caching of fallback fonts didn't work. It "worked" because we
didn't free the fonts... When we started doing that, the fallback
fonts were no longer cached.
Another solution would have been to keep the cached fallback fonts
around until exit, and free them there. But that didn't seem very
clean.
So, for now, load *all* fallbacks when instantiating a
primary (non-fallback) font.
Note that this slows down initial startup time.
This greatly improves the performance when loading user-configured
fallback fonts.
Previously, we had to re-load these fallback fonts over and over again
for each (new) glyph.
There must be at least one scrolling row. I.e. the bottom margin must
be larger than the top margin.
Note that trying to set an invalid region really will
be *ignored*. I.e. we *don't* reset the scrolling region.
This conforms to xterm's behavior.
Not all compositors support buffer re-use. I.e. they will call the
frame callback *before* the previous buffer has been
released. Effectively causing us to swap between two buffers.
Previously, this made us enter an infinite re-render loop, since we
considered the window 'dirty' (and in need of re-draw) when the buffer
is different from last redraw.
Now, we detect the buffer swapping case; size must match, and we must
not have any other condition that require a full repaint.
In this case, we can memcpy() the old buffer to the new one, without
dirtying the entire grid. We then update only the dirty cells (and
scroll damage).
Note that there was a bug here, where we erased the old
cursor *before* checking for a new buffer. This worked when the buffer
had *not* changed.
Now that we need to handle the case where it *has* changed, we must do
the memcpy() *before* we erase the cursor, or the re-painted cell is
lost.
This makes foot work on Plasma, without burning CPU. The memcpy() does
incur a performance penalty, but we're still (much) faster than
e.g. konsole. In fact, we're still mostly on par with Alacritty.
This is used in the desktop startup notification protocol. We don't
support it (is it even used on Wayland?), but need to ensure programs
launced from within foot doesn't inherit it.
This ensures we always have a valid (but possibly incorrect) scaling
value. This allows us to simplify code that uses the scale - it
doesn't have to verify the scale if valid.
Furthermore, since render_resize() is the function that actually
updates term->scale, make sure to call it *before* updating the
cursor (otherwise, the cursor will use the old scaling value).
This makes -f,--font behave just like the configuration file option
'font'; the first font in the list is the primary font, and the
remaining fonts are fallback fonts used when a glyph cannot be found
in the primary font.
They where previously identical to the corresponding 'regular'
colors. Now, we've done a saturated add with 0x202020 (which seems to
be roughly the difference between the other regular and bright
colors).
This fixes an issue where sometimes the strikeout thickness where
truncated to 0 (e.g. Cascadia Code).
Note that we already do this for the underline calculations.
