I wasn't pleased with how text was rendering on a colored background,
and after some research I discovered that I was neglecting to convert
from sRGB to a linear RGB colorspace, and that this was causing the
blending to have inaccurate results.
This diff pulls in the palette crate to handle the heavy lifting.
It doesn't appear to have any especially fast optimizations for this
though, which is a shame because the blending code I was using
previously was largely integer math with few branches. The colorspace
conversion has several floating point operations and branches that
are unavoidable :-/
We run a bit hotter on the CPU but the results are much more pleasing
to the eye.
So that we no longer assume Operator Mono SSm.
We now default to `monospace`. I just tried this and the font metrics
appear to be wonky, so there's some tweaking to do.
This eliminates the zsh reversed % artifact issue.
Added a feature flag to turn on diagnostics even in release mode;
`cargo run --release --features debug-escape-sequences`
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.
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.
