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
Right now (Unicode 15.1), all valid variation sequences consist of a
single Unicode codepoint (followed by either VS-15 or VS-16).
Don't assume this is the case.
We don't actually handle longer sequences. But now we at least catch
such escapes, and error out.
Lookups in this table is not performance critical at all.
Thus, let's compact it to bring down the binary size of foot.
This brings the size of each entry down from 9 bytes to 6, bringing
the size of the whole thing down from 1647 bytes to 1098 bytes, saving
us 549 bytes.
At compile time, build a lookup table from the Unicode data file
'emoji-variation-sequences.txt'.
At run-time, when we detect a VS-15/16 sequence, do a lookup in this
table, and enforce the variation selector iff the sequence is valid.
Closes#1742
That is, instead of sometimes replying with a "source" encoded
string (where e.g. '\E' are returned just like that, and not as an
actual ESC), always unescape all string values.
This also includes \n \r \t \b \f \s, \^ \\ \ \:, as well as ^x-styled
escapes.
Closes#1701
Having the builtin terminfo DB as a table, with one entry per
capability/value pair was ineffective memory-wise - we ended up adding
~20K to the final binary size.
This patch changes the internal representation from a table, to a
single NULL-separated (and NULL-terminated) char array:
cap1-name \0 cap1-value \0 cap2-name \0 cap2-value \0
The capabilities are still sorted; to lookup a capability we need to
scan from the beginning until we either find a match, or until the
capabilities from the DB sort higher (lexicographically) than the
searched-for capability.
The terminfo char array is 3.3K - more better than before.
This script parses a terminfo source file and generates a C header
file with a static struct containing terminfo names and their values.
The table is sorted on the capability names
If width/height (that is, the *pixel* values) are 0, that means we are
early (or that foot is slow) - we’ve managed to reach this point
before the foot window has been mapped.
Or rather, before foot has loaded the primary fonts and calculated the
cell geometry. But that, and the initial mapping of the window is
tightly coupled.
To handle this case, detect when width or height is 0, an then wait
for SIGWINCH before trying again.
When randomizing the sixel width and height, use width/height + 1 in
the call to randrange(). This ensures the width/height is never 0, and
that the maximum width/height is half the window size, not slightly
less than that.
After emitting multiple color bands for each sixel row, the increased
amount of sixel data shifted the balance in the profiling data,
causing a performance regression in regular ASCII handling.
This _should_ only happen when we’re doing a partial PGO build, since
then the script is run in the parent terminal. In this case, the user
is expected to use --rows/--cols anyway.
Using Python's own PRNG should make the code cleaner and allow for
reproducible stimulus files if that is desired via setting --seed (at
least for the same versions of the script, changing the kind and/or
order of the random calls will of course impact the output in the
future).
I did the following substitutions:
* rand.read(1)[0] % n and struct.unpack('@H', rand.read(2))[0] % n →
random.randrange(n)
* rand.read(1)[0] → random.randrange(256)
* rand.read(n) → [random.randrange(256) for _ in range(n)]
(better alternative would have been random.randbytes(n), but is only
available for Python >= 3.9, switching to this in the future will
impact output)
* list[rand.read(1) % len(list)] → random.choice(list)
