Using the SHM extension of the X server saves us from sending ~1MB of
bitmap data to the server on many screen update operations for a
modestly sized terminal window.
SHM may not be available in some situations so we need to keep a
fallback that basically works. This is done via a helper enum
in xwin.rs.
I've removed the unused Pixmap class; the pixmap concept makes the
most sense for us only when SHM is available.
I thought it would be nice to use the default xterm palette, but
I really hate the contrast of its default blue on black, so switch
to the palette from my xterm config.
Track all the rendition bits described in the SGR section here:
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
Still need to hook up color matching against the color palette
as described for the 256 color mode flavor.
Actually, the flicker was caused by the back pixel setting on the
window; I spent a long time running this down and finally got the
clue from this crusade against flicker:
http://www.ruska.it/michal/flicker.html
The spacing between glyphs seems too wide. Need to figure this out.
A bunch of the integer vs float changes in this diff were a result
of trying to run this down, but success has been limited, and in fact
the spacing has increased as a result of making this more correct(!)
Initially I wanted to make the font code separate from
the main wterm executable in the hope that it would be
reusable. However, we do need to be able to reach in
to both the font implementation and the SDL texture
implementation in order to capture the glyph data
into textures, so let's just embrace it all being
in the same crate.
Trigger x-scaling based on the x_advance rather than the bitmap width.
Also account for the unicode width of the fragment when scaling.
The use of bearing_x was incorrect; we were subtracting it rather
than adding it and making the glyphs look terrible at smaller sizes.