We currently store up to 5 combining characters in any given
base+combining chain.
This adds a check for when that limit is about to be exceeded. When
this happens, we log the chain + the new combining character.
Since things will break anyway, we simply overwrite the last combining
character.
Instead of storing combining data per cell, realize that most
combinations are re-occurring and that there's lots of available space
left in the unicode range, and store seen base+combining combinations
chains in a per-terminal array.
When we encounter a combining character, we first try to pre-compose,
like before. If that fails, we then search for the current
base+combining combo in the list of previously seen combinations. If
not found there either, we allocate a new combo and add it to the
list. Regardless, the result is an index into this array. We store
this index, offsetted by COMB_CHARS_LO=0x40000000ul in the cell.
When rendering, we need to check if the cell character is a plain
character, or if it's a composed character (identified by checking if
the cell character is >= COMB_CHARS_LO).
Then we render the grapheme pretty much like before.
We only used utf8proc to try to pre-compose a glyph from a base and
combining character.
We can do this ourselves by using a pre-compiled table of valid
pre-compositions. This table isn't _that_ big, and binary searching it
is fast.
That is, for a very small amount of code, and not too much extra RO
data, we can get rid of the utf8proc dependency.
If the client sent the sequence SAB, where SA does NOT have a composed
representation, but SB does, the old code would compose SB and throw
away A.
This patch fixes this by only allowing a compose if there aren't
any pre-existing combining characters.
This is basically just a loop that renders additional glyphs on top
off the base glyph.
Since we now need access to the row struct, for the combining
characters, the function prototype for 'render_cell()' has changed.
When rendering the combining characters we also need to deal with
broken fonts; some fonts use positive offsets (as if the combining
character was a regular character), while others use a negative
offset (to be used as if you had already advanced the pen position).
We handle both - a positive offset is rendered just like a regular
glyph. When we see a negative offset we simply add the width of a cell
first.
When we detect a combining character, we first try to compose it with
the base character (like before).
When this fails, we instead add the combining character to the base
cell's combining characters array.
The reason for using a composed character when possible is twofold:
one, the rendered glyph will look better since it will be a single
glyph instead of two separate glyphs (possibly from different
fonts(!)). And two, for performance. A composed glyph is a single
glyph to render, while a decomposed glyph sequence means the renderer
has to render multiple glyphs for a single cell.
This is the *only* place combining characters are reset. In
particular, we do *not* reset them in a normal cell erase.
This is a performance design decision - clearing the combining
characters in erase is way too slow.
This way, we clear it only when we *have* to. Anything looking at the
combining characters must first ensure the base character is not 0.
The data is *not* added to the cell struct, since that one is too
performance critical.
Instead, the data is added as a separate array in the row struct.
This allows our performance critical code paths that e.g. clear cells
to perform as before.
The way things works right now, we cannot enable the ptmx FDM callback
right away. We need to wait for the Wayland window to have been
configured.
Before the window is configured, we don't have a size, and no
grid. Thus, if we try to process ptmx data we'll crash since we have
no where to write it to.
So, registering the ptmx fd with the FDM is now delayed until we've
received the first 'configure' event from Wayland.
Use four threads to load the four primary font variants - normal,
bold, italic and bold italic.
This speeds up initial startup, and reloading of fonts on a DPI
change.
That is, deal with monitors being unplugged.
At least on Sway 1.4, surfaces are not unmapped before the output is
removed. Thus, in addition to free:ing the monitor resources, we also
need to update all terminals that are mapped on this output - remove
the output from their "mapped on" list.
