Short term, we want to break out the wayland backend from the terminal
struct. Long term, we might want to support multiple windows.
One step towards both the above is separating global wayland objects
from per-window objects.
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 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).
Use the 'yellow' color from the 'regular' range of colors (SGR 33) for
background when we have a match, or 'red' from the 'regular' range of
colors (SGR 31) when we don't have a match.
Foreground uses the 'black' color from the regular range of
colors (SGR 30).
The old baseline calculation was copy-pasted to a couple of places,
and also assumed that the font's height was equal to ascent+descent.
While this is typically true, it isn't necessarily so.
Now, we assume that height >= ascent+descent, and then position the
baseline in "center" (but adjusted for the descent).
This adds a new state, 'is_searching'. While active, input is
re-directed, and stored in a search buffer. In the future, we'll use
this buffer and search for its content in the scrollback buffer, and
move the view and create a selection on matches.
When rendering in 'is_searching', everything is dimmed. In the future,
we'll render the current search buffer on-top of the dimmed "regular"
terminal output.
With this assumption, we can replace 'a % b' with 'a & (b - 1)'. In
terms of instructions, this means a fast 'and' instead of a slow
'div'.
Further optimize scrolling by:
* not double-initializing empty rows. Previously, grid_row_alloc()
called calloc(), which was then followed by a memset() when
scrolling. This is of course unnecessary.
* Don't loop the entire set of visible rows (this was done to ensure
all visible rows had been allocated, and to prefetch the cell
contents).
This isn't necessary; only newly pulled in rows can be NULL. For
now, don't prefetch at all.
Our surface may be on multiple outputs at the same time. In this case,
we use the largest scale factor, and let the compositor down scale on
the "other" output(s).
When rendering either the 'bar' or 'underline' cursor styles, only use
the configured "cursor color" if it has actually been configured.
If it hasn't, use the current foreground color.
The 'attributes' struct is now 8 bytes and naturally packed (used to
be 9 bytes, artificially packed).
'cell' struct is now 12 bytes, naturally packed (used to be 13 bytes,
artificially packed).
Furthermore, the glyph is stored as a wchar instead of a char*. This
makes it easier (faster) to do glyph lookup when rendering.
Fonts are now loaded with FT_LOAD_COLOR and we recognize and support
the FT_PIXEL_MODE_BGRA pixel mode.
This is mapped to a CAIRO_FORMAT_ARGB32 surface, that is blitted
as-is (instead of used as a mask like we do for gray and mono glyphs).
Furthermore, since many emojis are double-width, we add initial
support for double-width glyphs.
These are assumed to always be utf8. When PRINT:ing an utf8 character,
we check its width, and add empty "spacer" cells after the cell with
the multi-column glyph.
When rendering, we render the columns in each row backwards. This
ensures the spacer cells get cleared *before* we render the glyph (so
that we don't end up erasing part of the glyph).
Finally, emoji fonts are usually bitmap fonts with *large*
glyphs. These aren't automatically scaled down. I.e. even if we
request a glyph of 13 pixels, we might end up getting a 100px glyph.
To handle this, fontconfig must be configured to scale bitmap
fonts. When it is, we can look at the 'scalable' and 'pixelsizefixup'
properties, and use these to scale the rendered glyph.
