This adds in-terminal rendering for the powerline glyphs E0B4 and E0B6,
similar to how we are rendering the triangle shapes currently.
The circle glyphs use a much more complex rendering due to the nuances
of drawing them: we use a midpoint algorithm for drawing on a 4x
supersampled matrix, fill, and then downsample. We use the same
downsampling approach as is done in the arc box drawing code.
The midpoint variant we're using here is described by Dennis Yurichev:
https://yurichev.com/news/20220322_circle/, although there are similar
variants elsewhere (some cited at the bottom of his article).
This adds the Powerline face to our set of built-in faces, which
represents glyphs that are used to draw Powerline-style shell prompts
and status lines.
Since these are used similar to box-drawing characters, alignment is
important, and this gives us the most control in preventing related
artifacts.
This initial commit is scaffolding and support for the various solid
triangles - additional glyphs will come in other commits.
Fixes#675.
Fixes#757
The x/y is unsigned (as it should be, since top-left is 0,0). In the
case of a very small grid size and certain thickness settings, its
possible to overflow. In this scenario, the only reasonable thing to do
is just clamp to 0 because some sprites are going to look weird with
small enough grids anyways.
Fixes#143
There were multiple issues with the previous calculation. First, we
expected dash width COULD be negative and protected against it, but our
dash width calculation type was unsigned! With the proper font metrics,
this led to an underflow safey panic.
Second, as part of the dash width calculation, we are tryign to downstep
the size of the gaps so we can try to fit dashes within a cell. But we
were not using those adjusted gap sizes. With the proper font metrics,
this could lead to an assertion failure seen in #143.
This fixes the calculations. They produce the same numbers, but do so in
a more Zig-idiomatic way while fixing the above two issues.
