../../box-drawing.c: In function 'box_drawing':
../../box-drawing.c:2774:13: error: 'y1' may be used uninitialized in this function [-Werror=maybe-uninitialized]
2774 | int y0, y1;
| ^~
../../box-drawing.c:2774:9: error: 'y0' may be used uninitialized in this function [-Werror=maybe-uninitialized]
2774 | int y0, y1;
| ^~
We’re using floating point math, as a way to ensure that sextant primitives
overlap, rather than leaving empty spaces, or being uneven, when the cell
width/height isn’t divisible with 2 (width) or 3 (height).
This gets rid of all floating point math from the sextant drawing functions.
That is, encode which “pieces” make up each quad in a static array, and use a
single function to draw all quads using the four primitives “upper left/right,
lower left/right”.
We render the inverted wedges by first rendering a non-inverted triangle, and
then inverting it with PIXMAN_OP_OUT.
In cases where truncating and round():ing the triangle points have different
results, the final, inverted wedge ends up being unaligned with the
corresponding sixel(s).
This patch fixes that by handling the pre-inverted triangles
specifically. I.e. we don’t re-use the same triangle coordinates as the
corresponding non-inverted triangle.
When enabled, shades are rendered as solid blocks, using a darker
variant of the current foreground color.
When disabled, shades are instead rendered in a checker box pattern,
using the foreground color unmodified.
Default is enabled.
When drawing on an a8 buffer, apply antialiasing to LIGHT ARCs. This
is done by supersampling; draw to a 4 times bigger buffer, then
downsample, where each downsampled pixel is the average of the
corresponding 4x4 pixel from the supersampled buffer.
We also need to take supersampling into account while adjusting the row
and col when pixel aligning the arcs with the regular
horizontal/vertical lines.
The shape of the ARCs can still be improved. Still, this is a much
needed improvement over the current implementation.
Closes#279
We don’t have a method to draw the arcs using pixman yet. Work around
this by replacing the a8 buffer with an a1 buffer, and render the arcs
using our old, non-antialiased, way.
When rendering to an a8 surface, render shades using “transparent”
pixman rectangles.
When these glyphs are composited with a color, the resulting look is
the color, but darkened.
Use pixman_image_fill_rectangles() to render horizontal and vertical
lines.
Despite the name, this *is* the appropriate function to use, since our
lines *do* have a thickness, and thus *are* rectangles.
If the value is specified without a unit, then the value is assumed to
be in points, subject to DPI scaling.
The value can optionally have a ‘px’ suffix, in which case the value
is treated as a raw pixel count.
“The optimize attribute should be used for debugging purposes
only. It is not suitable in production code.”
Luckily, it seems it really isn’t needed anymore; with all the other
size optimizations that has been done since this was introduced, there
is no longer any difference with or without this pragma.
Mixed here refers to mixed thickness - the lines thickness doesn’t
match the thickness of an abstract, orthogonal line going through the
middle of the cell.
When mirroring an arc, we need to adjust the mirrored position if the
arc’s position in the cell is asymmetrical. This happens when *either*
the line is odd sized, *or* the cell is. But not when both are.
Thus, we can simply do a ‘thickness % 2 ^ width % 2’ when adjusting
the position.
Describe this in a comment.
