There’s a chance the resize timeout FD was closed, and *reused*, after
epoll() told us the FD is readable, but before our callback runs.
Thus, closing the FD provided as an argument is dangerous, as it may
refer to something completely different.
A narrow, but offset:ed glyph should still be considered double
width.
This patch also fixes a crash, when the maybe-double width glyph is in
the last column. This is a regression.
The previous implementation stored compose chains in a dynamically
allocated array. Adding a chain was easy: resize the array and append
the new chain at the end. Looking up a compose chain given a compose
chain key/index was also easy: just index into the array.
However, searching for a pre-existing chain given a codepoint sequence
was very slow. Since the array wasn’t sorted, we typically had to scan
through the entire array, just to realize that there is no
pre-existing chain, and that we need to add a new one.
Since this happens for *each* codepoint in a grapheme cluster, things
quickly became really slow.
Things were ok:ish as long as the compose chain struct was small, as
that made it possible to hold all the chains in the cache. Once the
number of chains reached a certain point, or when we were forced to
bump maximum number of allowed codepoints in a chain, we started
thrashing the cache and things got much much worse.
So what can we do?
We can’t sort the array, because
a) that would invalidate all existing chain keys in the grid (and
iterating the entire scrollback and updating compose keys is *not* an
option).
b) inserting a chain becomes slow as we need to first find _where_ to
insert it, and then memmove() the rest of the array.
This patch uses a binary search tree to store the chains instead of a
simple array.
The tree is sorted on a “key”, which is the XOR of all codepoints,
truncated to the CELL_COMB_CHARS_HI-CELL_COMB_CHARS_LO range.
The grid now stores CELL_COMB_CHARS_LO+key, instead of
CELL_COMB_CHARS_LO+index.
Since the key is truncated, collisions may occur. This is handled by
incrementing the key by 1.
Lookup is of course slower than before, O(log n) instead of
O(1).
Insertion is slightly slower as well: technically it’s O(log n)
instead of O(1). However, we also need to take into account the
re-allocating the array will occasionally force a full copy of the
array when it cannot simply be growed.
But finding a pre-existing chain is now *much* faster: O(log n)
instead of O(n). In most cases, the first lookup will either
succeed (return a true match), or fail (return NULL). However, since
key collisions are possible, it may also return false matches. This
means we need to verify the contents of the chain before deciding to
use it instead of inserting a new chain. But remember that this
comparison was being done for each and every chain in the previous
implementation.
With lookups being much faster, and in particular, no longer requiring
us to check the chain contents for every singlec chain, we can now use
a dynamically allocated ‘chars’ array in the chain. This was
previously a hardcoded array of 10 chars.
Using a dynamic allocated array means looking in the array is slower,
since we now need two loads: one to load the pointer, and a second to
load _from_ the pointer.
As a result, the base size of a compose chain (i.e. an “empty” chain)
has now been reduced from 48 bytes to 32. A chain with two codepoints
is 40 bytes. This means we have up to 4 codepoints while still using
less, or the same amount, of memory as before.
Furthermore, the Unicode random test (i.e. write random “unicode”
chars) is now **faster** than current master (i.e. before text-shaping
support was added), **with** test-shaping enabled. With text-shaping
disabled, we’re _even_ faster.
fcft’s view of how many columns a grapheme cluster is may differ from
our own. Make sure the rendered glyph matches the number of columns
that were allocated when the cluster was printed.
The configure event asks the client to change its decoration
mode. The configured state should not be applied immediately.
Clients must send an ack_configure in response to this event.
See xdg_surface.configure and xdg_surface.ack_configure for
details.
In particular, ”the configured state should *not* be applied
immediately”.
Instead, treat CSD/SSD changes like all other window dimension related
changes: store the to-be mode in win->configure, and apply it in the
surface configure event.
This fixes an issue where foot incorrectly resized the window when the
server switched between CSD/SSD at run-time.
This option controls the foreground color of the
minimize/maximize/close buttons. I.e. the color used to draw the
minimize/maximize/close glyphs.
It defaults to default background color.
Using the frame callback works most of the time, but e.g. Sway doesn’t
call it while the window is hidden, and thus prevents us from updating
the title in e.g. stacked views.
This patch uses a timer FD instead. We store a timestamp from when the
title was last updated. When the application wants to update the
title, we first check if we already have a timer running, and if so,
does nothing.
If no timer is running, check the timestamp. If enough time has
passed, update the title immediately.
If not, instantiate a timer and wait for it to trigger.
Set the minimum time between two updates to ~8ms (twice per frame, for
a 60Hz output, and ~once per frame on a 120Hz output).
Closes#591
TAB (\t) move the cursor to the next tab stop. That’s it, according to
the specification.
However, many terminal emulators try to keep tabs in the grid, to be
able to e.g. copy them. That is, copying a text chunk containing tabs
should result in tabs being pasted, not spaces.
In order to do that, we need to print a tab character to the grid. To
improve text reflow of tabs, we also print spaces to the subsequent
cells, up until (but not including) the next tab stop.
However, we can only do this if all the cells between the cursor and
the next tab stop are empty, since (obviously), we cannot overwrite
pre-existing characters.
Finally, while some fonts render tabs as spaces (i.e. an empty glyph),
some use a glyph representing “unprintable” characters, or
similar. Thus, we need to exclude cells with tab characters when
rendering.
This matches XTerm behavior, and fixes vttest 11.6.6.2:
Test non-VT100 ->
Test ISO-6429 colors ->
Test of VT102-style features with BCE ->
Test of screen features
When enabled, PUA (Private Usage Area) codepoints are always treated
as double-width glyphs, regardless of the actual glyph width.
Requires allow-overflowing-double-width-glyphs=yes
Works in pretty much the same way as ‘beam-thickness’, except that the
default value is “the font’s underline thickness”.
This means, that when unset, the cursor underline thickness scales
with the font size.
But, when explicitly set, either to a point size value, or a pixel
size, it remains fixed at that size.
Closes#524
It _may_ be acceptable in e.g. tiling WMs, where windows are seldom
resized interactively.
But in a stacking WM where the typical way of resizing windows is by
interactive resizes, this spams way too much.
Instead of using CELL_SPACER for *all* cells that previously used
CELL_MULT_COL_SPACER, include the remaining number of spacers
following, and including, itself. This is encoded by adding to the
CELL_SPACER value.
So, a double width character will now store the character itself in
the first cell (just like before), and CELL_SPACER+1 in the second
cell.
A three-cell character would store the character itself, then
CELL_SPACER+2, and finally CELL_SPACER+1.
In other words, the last spacer is always CELL_SPACER+1.
CELL_SPACER+0 is used when padding at the right margin. I.e. when
writing e.g. a double width character in the last column, we insert a
CELL_SPACER+0 pad character, and then write the double width character
in the first column on the next row.
In some cases, the underline position (typically provided by the font,
mind you), end up below the cell, making it visible.
Note that below the cell here means below the line. I.e. the font
provided underline position is below the font provided line height...
Oh well.
Doing this in foot rather than fcft, since other applications
typically don’t have to clip the rendered text.
Closes#503
Older version of Plasma/KWin had an issue where buffer damage recorded
before the buffer was attached were ignored. This appears to have been
fixed now.
* Break out cursor cell dirtying to separate functions
* Break out handling of double buffering
* Handle buffers with age > 1 (we’re swapping between more than 2
buffers)
* Detect full screen repaints, and skip re-applying old frame’s damage
* Use an allocated array insted of a tll list for old frame’s scroll damage
* When logging frame rendering time, including the amount used for
double buffering.
When re-applying the previous frame’s damage (due to us being forced
to double buffer), subtract the current frame’s damage from the
region-to-copy when there’s no scroll damage on the current frame.
When the current frame doesn’t have any scroll damage, the current
frame’s damage is in the same coordinate system as the previous
frame’s damage, and we can safely remove it from the region we copy
from.
When we are forced to swap between two buffers, re-apply the old
frame’s damage to the current buffer, before applying the current
frame’s damage.
First, while applying this frame’s scroll damage, copy it to the
buffer’s scroll damage list (so that we can access it via
term->render.last_buf).
Also, when iterating and rendering the grid, build a pixman region of
the damaged regions. This is currently done on a per-row basis. This
is also stored in the buffer.
Now, when being forced to double buffer, first iterate the old
buffer’s damage, and re-apply it to the current buffer. Then,
composite the old buffer on top of the current buffer, using the old
frame’s damage region as clip region. This effectively copies
everything that was rendered to the last frame. Remember, this is on a
per-row basis.
Then we go on and render the frame as usual.
Note that it would be _really_ nice if we could subtract the current
frame’s damage region from the clip region (no point in copying areas
we’re going to overwrite anyway). Unfortunately, that’s harder than it
looks; the current frame’s damage region is only valid *after* this
frame’s scroll damage have been applied, while the last frame’s damage
region is only valid *before* it’s been applied.
Translating one to the other isn’t easy, since scroll damage isn’t
just about counting lines - there may be multiple scroll damage
records, each with its own scrolling region. This creates very complex
scenarios.
By default, age all matching buffers that are busy (i.e. in use by the
compositor).
This allows us to detect whether we can apply the current frame’s
damage directly, or if we need to prepare the buffer first (e.g. copy
old buffer, or re-apply last frame’s damage etc).
In all other cases, alpha is disabled. This includes:
* Palette- or RGB-colors matching the default background color
* When any kind of reverse video is enabled (e.g. DECSCNM, or ANSI
reverse)
* Rename cursor.style value ‘bar’ to ‘beam’. ‘bar’ remains recognized,
but should eventually be deprecated and then removed.
* Add ‘cursor.beam-thickness’ option, a pt-or-px value specifying the
thickness of the beam cursor. Defaults to 1.5pt.
* Rename (and export) pt_or_px_as_pixels() to
term_pt_or_px_as_pixels()
* Change term_pt_or_px_as_pixels() to round point values instead of
truncating them.
When rendering a selected/highlighted cell where the foreground and
background colors are the same, invert the background color to make
the selected text legible.
Closes#455
When ‘bold-text-in-bright’ is set ‘to palette-based’, colors matching
one of the 8 regular palette colors are brightened by using the
corresponding bright palette color.
Other colors, or all colors if ‘bold-text-in-bright’ is set to
‘yes|true’, are brightened by increasing the luminance.
We have no guarantee that sub-surfaces extending outside the window
geometry are rendered correctly (if at all).
For example, both Sway and River will render the window border on top
of the sub-surface.
Future versions of Sway may clip the sub-surface.
Since jump-labels are positioned slightly above, and to the left of
the URLs first character, having a label on either the top row, or on
the first column, will likely position it outside the window. This is
handled by simply setting x/y to 0 (or, to -margin, since the label
coordinate is later offsetted with the window margins).
Second, if the label is very long, it may extend outside the
window. This is very unusual for labels only showing the key, and not
the URL itself, but could happen in this case too, if e.g. the user
has configured double-width key characters.
This is handled by calculating its maximum width, and then truncating
the label.
Although very unlikely, it is possible for a label to also extend
outside the window’s vertical size. This could happen for very small
font sizes, where the label’s own margins are large, relative to the
font size. This case is currently not handled.
Closes#443
