Previously, we triggered a theme reload on output changes. This is
completely wrong. We may get a new output with a scale different from
the output the pointer is actually on.
Now, we store the current scale along with the theme. We then trigger
a call to reload the xcursor theme *every* time the pointer enters a
surface. When it does, we use the current scale factor of the terminal
that owns that surface.
If the terminal covers multiple outputs, with different scale factors,
we'll use the largest scale factor. This may not be 100% correct. But
to fix that, we'd need to track which regions of a surface are mapped
on which outputs. Too complicated I say.
When resizing the font on-the-fly, we now do a complete
font-reload (this is basically what fcft_size_adjust() did anyway).
To get the correct size, we maintain the current size ourselves.
We get the initial size from the user-provided font pattern, by
converting the string to an FcPattern, and using FcPatternGet() to
retrieve both the FC_SIZE and FC_PIXEL_SIZE attributes. These
attributes are then removed from the pattern, and the pattern is
converted back to a string.
The terminal struct maintains a copy of the font sizes. These are
initially set to the sizes from the config.
When the user resizes the font, the terminal-local sizes are
adjusted. To ensure the primary and user-configured fallback fonts are
resizes equally much, convert any pixel sizes to point sizes at this
point.
When the font size is reset, we reload the font sizes from the
config (thus once again returning actual pixel-sizes, if that's what
the user has configured).
The logic that breaks out of sixel loops does not work for rows that
has already wrapped around.
Thus, we need to destroy sixels that are about to be scrolled
out *before* we actually scroll.
Since this is the *only* time we destroy sixels (instead of
overwriting it), rename the sixel functions. And, since they now do a
very specific thing, they can be greatly simplified (and thus faster).
If changing the font size causes the cell size to decrease, either
horizontally or vertically (or both), then delete all sixels since the
grid space they allocated no longer is enough to hold the images.
Since the images are sorted, we can break out of the loop as soon as
we detect an image that *ends before* the rectangle's top starts.
In order for the row comparisons to work, the row numbers must be
re-based against the current scrollback offset, or the
scrollback *end*, to be precise.
Since the images are sorted, we can break out of the loop as soon as
we detect an image that *ends before* the row we're looking for.
In order for the row comparisons to work, the row numbers must be
re-based against the current scrollback offset, or the
scrollback *end*, to be precise.
The sixel images are sorted, that's true. But in order for our row
numer comparisons to actually work, we need to rebase all numbers
against the current scrollback offset (or, the scrollback *end*, to be
precise).
The sixel list is sorted, with the most recent images *first* in the
list (and thus the "oldest" images are at the back).
This means we can break out of the loop when we see a sixel
that *ends before* the current view starts.
As a minor optimization, we also recognize sixels that *start after*
the current view ends. We can't break out of the loop, but we can skip
trying to render them (they wouldn't have been rendered, but more work
would have been done in render_sixel() to reach this conclusion).
Our sixel handling code requires sixels to *not* cross the scrollback
wrap around.
Until we've fixes the reflow code that split up such sixels (much like
we do when we generate a sixel), simply delete it.
