With dpi-aware=auto (the default), scale fonts using DPI *only*
if *all* available monitors have a scaling factor of one.
The idea is this: if a user, with multiple monitors, have enabled
scaling on *at least* one monitor, he/she has most likely done so to
match the size of his/hers other monitors.
For example, if the user has one monitor with a scaling factor of one,
and another one with a scaling factor of two, he/she expects things to
be twice as large on the second monitor.
If we (foot) scale using DPI on the first monitor, and using the
scaling factor on the second monitor, foot will *not* look twice as
big on the second monitor (this was the old behavior of
dpi-aware=auto).
Part of #714
FOOT_DEFAULT_TERM is a string literal passed as a -D argument to
the compiler, so it can just be concatenated with the other string
literals, instead of being formatted with printf().
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
