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.
This reduces the size of the foot binary by ~4K; all the quad
macros called ceil() and floor() twice per macro, which caused many
float -> int -> float conversions in the expanded code.
By using functions instead, there’s no expansion - the conversion only
happens in one (well, four) places.
We were using so many function arguments that a lot of the emitted
code was just stack push and pops to pass around arguments.
Bundle the buffer data, width, height, stride, and current DPI, into a
single ‘buf’ argument. This greatly reduces the number of arguments to
all functions.
