Too large dots make them harder to distinguish, when the spacing
between them is small.
Prefer increasing the spacing, instead of increasing the dot
size. This looks better at small font sizes in particular.
The box_drawings array is now quite large, and uses up ~4K
when *empty*.
This patch splits it up into three separate, dynamically allocated
arrays; one for the traditional box+line drawing and block elements
glyphs, one for braille, and one for the legacy computing symbols.
When we need to render a glyph, the *entire* array (that it belongs
to) is allocated.
I.e this is one step closer to a dynamic glyph cache (like the one
fcft uses), but doesn’t go all the way.
This is especially nice for people with
‘box-drawings-uses-font-glyphs=yes’; for them, the custom glyphs now
uses 3*8 bytes (for the three array pointers), instead of 4K.
Render braille ourselves, instead of using font glyphs. Decoding a
braille character is easy enough; there are 256 codepoints,
represented by an 8-bit integer (i.e. subtract the Unicode codepoint
offset, 0x2800, and you’re left with an integer in the range 0-255).
Each bit corresponds to a dot. The first 6 bits represent the upper 6
dots, while the two last bits represent the fourth (and last) row of
dots.
The hard part is sizing the dots and the spacing between them.
The aim is to have the spacing between the dots be the same size as
the dots themselves, and to have the margins on each side be half the
size of the dots.
In a perfectly sized cell, this means two braille characters next to
each other will be evenly spaced.
This is however almost never the case. The layout logic currently:
* Set dot size to either the width / 4, or height / 8, depending on
which one is smallest.
* Horizontal spacing is initialized to the width / 4
* Vertical spacing is initialized to the height / 8
* Horizontal margins are initialized to the horizontal spacing / 2
* Vertical margins are initialized to the vertical spacing / 2.
Next, we calculate the number of “remaining” pixels. That is, if we
add the left margin, two dots and the spacing between, how many pixels
are left on the horizontal axis?
These pixels are distributed in the following order (we “stop” as soon
as we run out of pixels):
* If the dot size is 0 (happens for very small font sizes), increase
it to 1.
* If the margins are 0, increase them to 1.
* If we have enough pixels (need at 2 horizontal and 4 vertical),
increase the dot size.
* Increase spacing.
* Increase margins.
Closes#702
Appears to work, but cage spams a lot of
00:00:08.026 [types/wlr_output.c:720] Basic output test failed for HEADLESS-1
00:00:08.036 [types/wlr_output.c:720] Basic output test failed for HEADLESS-1
All scripts are in the ‘pgo’ directory:
* options: command line options for generate-alt-random-writes.py,
sourced by other scripts.
* pgo.sh: top-level script, generates a meson build directory, selects
a PGO method, generates the profiling data, re-configures the meson
build directory and does the final build.
This script is intended to be used by end-users, and shows _how_ to
integrate the script primitives.
Build servers will most likely *not* want to use this script as-is.
* partial.sh: generates alt-random-write data and runs “foot{,client}
--version”, and then feeds the alt-random data to the PGO helper
binary. Does not require a running Wayland session. Touches
$blddir/pgo-ok on success.
* full-inner.sh: runs “footclient --version”, and then a complex
“foot” command that first generates alt-random-write data, and then
“cat’s” it. Requires a running Wayland session, *but*, this script
is usually not called directly (see below). Touches $blddir/pgo-ok
onsucces..
* full-current-session.sh: runs full-inner.sh. That is, it runs foot
in the currently running Wayland session. Note that this will pop up a
foot window.
* full-headless-sway.sh: generates a custom Sway configuration that
exec’s foot-headless-sway-inner.sh (see below), and then executes a
headless Sway. In other words, this script does a *full* PGO build,
but *without* requiring a running Wayland session. Requires Sway >=
1.6.2.
* full-headless-sway.sh: runs full-inner.sh + “swaymsg exit”.
To do a custom PGO build, without using pgo.sh, you’d need to:
CFLAGS=”$CFLAGS -O3” meson --buildtype=release -Db_lto=true
meson configure -Db_pgo=generate
ninja
ninja test (only needed if tllist+fcft are built as subprojects)
Run *one* of:
- partial.sh
- full-current-session.sh
- full-headless-sway.sh
meson configure -D b_pgo=use
ninja
Usage: meson-pgo.sh auto|partial|full <source-dir> <build-dir> <meson-options>
Note: build-dir must *not* exist before the script is run (but if it
does, the script will tell you so, and exit).
Supported compilers: gcc and clang
The script does *not* add _any_ custom meson options, except configure
-Db_pgo. Thus, you probably want to call it like this:
meson-pgo.sh auto . /tmp/foot-pgo-build --buildtype=release -Db_lto=true
Under certain circumstances, GNOME will send multiple pointer button
press events, without any release or leave events in between.
This trips up our button tracking.
Workaround, by replacing the existing state for the pressed button
with the new state.
Previously, debug builds would assert (and thus crash), while release
builds would have multiple states for the same button,
causing (probably) issues like the title bar not being usable (as in,
cannot be dragged, buttons not working etc).
Hopefully closes#709
Instead, do the palette lookup when we receive the DECGCI (i.e. when
the palette entry is selected), and store the actual color value in
our sixel struct.
We have all information we need to calculate the default background
color in sixel_init():
* Whether the image have transparency or not
* The current ANSI background color
