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.
