Adds some plumbing to track the current mouse position and
extract the hyperlink from the cell that is being hovered over.
We render those cells with underline, possibly in a different color.
We don't yet do anything on click.
This felt a bit repeatey and it pre-dated the TerminalHost trait.
I'd like to remove it completely but there are some frustrating and
fiddly lifetime concerns with mutable TerminalHost reference so I'm
hiding it from the public interface and bridging it the answerback
stream into the host at the bottom of the advance_bytes method for
now.
This also improves perf. The issue was that the erase of the whole
line of the background may be observed by the X server when SHM is
enabled because we don't wait for the exposure/copy to the window
pixmap before updating the same row fractionally later.
Avoiding the unconditional erase and just painting the full cell
contents over means that there's no opportunity for a visible flash.
In addition, since we render the cells background individually, that
erase was not needed.
This should save us some work and take some load off the cpu.
This wasn't correctly handling double-width or ligatures. In addition,
don't respect the x_advance outside of a ligature run, as it can result
in slightly offset columns for example when `ls -l` shows `--` and that
sequence has a slightly less wide ligatured rendition.
```
echo -e '\e[4mu--nder\e[0m \e[21mdo--uble\e[0m \e[9mst--rike\e[0m'
```
We were panicking when rendering the || ligature, which is narrower
than we were expecting. There was also a weird looking assert
that was triggering if we got path the math overflow.
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.
This is most noticable with a cursive italic font. When we
were dividing the glyph into cell slices, we could leave off
a 2 pixel wide strip from the last of the sequence and this
looked nasty.
This diff also adjusts come calculations to use the width and
height from the current TextStyle. Whether this is more or
less correct remains to be seen :-p
This enables selecting an italic font when the cell is italic,
but has more power beyond just that simple property.
This runs a little hot on the CPU so there's probably some caching and
tweaking that can be done to make the evaluation a bit cheaper.
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.
We weren't quite right with handling the cursor around double-width
characters. We're now a bit more robust at this because we're
clustering and taking pains to consider the printable width of the
cell as well as the width of the shaped (eg: with contextual ligatures)
glyph.
There may still be issues with contextual ligatures of length 3,
but I haven't managed to nail down exactly the issue yet.
This unlocks pressing `b` in `less` and `more` to scroll backwards.
To facilitate this I had to do a better job at scrolling up and down,
so beef up the code to enable that. Scroll regions still need some
work; test case for that is running vim and then opening help.
Also: fixup the y position when rending rows; it was off by one row.
We now keep track of the dirty status on a per-line basis
and use that status to realize when we need to repaint a portion
of the screen. This reduces the compute cost of redrawing
quite significantly; we're no longer on `top` when we're running
`top`!
The simpler escape sequences were getting a bit boiler-platey and long,
so hoist them up and perform matching at the main level. This has the
side effect of discarding params after a match; that's fine for these
as it only seems to be important for the SGR 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.
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.
