Handle these on a higher abstraction level. The low level functions
that detect sixel intersections now assume the specified rectangle (or
line region) does *not* cross the wrap-around.
This is ensured by detecting a wrap-around region before hand, and
splitting it up into two, non wrapping regions.
This reduces the burden on sixel_split_by_rectangle(), which would
otherwise consider the newly added/splitted sixels. Since we already
know they aren't covered by the specified rectangle, we can skip that.
This function splits a sixel image into up to four pieces. The four
pieces correspond to the relative complement (set difference) of the
sixel image and the specified rectangle.
Use this function when (possibly) overwriting existing sixel images
when generating a new one, i.e. in sixel_unhook().
Instead of completely erasing a sixel image when it is being
"overwritten" (text is printed somewhere within the image, or another
sixel image is emitted within the first image), split it up into up to
four pieces: 'above', 'below', 'to-the-left' and 'to-the-right'.
This is currently very un-optimized, but seems to produce correct
results.
We used to auto-resize images to always be a multiple of 6.
This is incorrect. The client may, for example, have specified a size
to align the image to a cell boundary, which may not be a multiple of
6.
Furthermore, in e.g. Jexer, which splits up an image into stripes,
that the next image would "overwrite" the previous one. Since the next
image was started on a cell row that the previous image had overflowed
into.
Since we don't have the original palette index in already rendered
cells, we compare the color *value*. If it matches, we assume this was
the color index used, and updates the cell's color.
Note that for performance reasons, we only update the current
grid. This is of course wrong, strictly speaking.
However, it is expected that _Set Color_ is used by full-screen
applications using the alternate grid.
A client can re-use the palette between images. Resetting the palette
breaks this.
Now we initialize the palette on demand, and resets it when the
palette size is changed (by the client).
This used to work before because we had a "global" clip region on the
text area, excluding the margins.
When we introduced per-cell clipping, this global clip region was
removed, and the background drawing code could now overflow into the
margins.
This fixes it by setting the cell clip region not just when rendering
a glyph, but before we render the cell background.
Our home rolled clip-to-cell code was, obviously, not correct.
The original problem was that we couldn't use pixman clipping since we
have multiple threads writing to the same pixman image, and thus there
would be races between the threads setting clipping.
The fix is actually simple - just instantiate one pixman
image (referencing the same backing image data) for each rendering
thread.
This would be done cleaner by using destination clipping in pixman,
but since we have multiple threads rendering cells simultaneously,
that is not possible.
We also cannot use source clipping since we need to offset the
destination x,y coordinates with the glyph offsets.
So, roll our own clipping by not allowing the x,y offsets to go
outside the cell boundaries, and adjusting the glyph offset
accordingly.
Closes#21
Since foot is pretty aggressive about spawning the client early, it
was possible for a fast client to read a 0x0 terminal size. Not all
clients coped well.
Closes#20.
