Introduces `fill`, which fills between two `Fraction`s, use this instead
of `yHalfs` and friends wherever they're used, which also means we can
remove `rect`.
This commit does change alignment of the vertical/horizontal eighths in
certain cell sizes, but the change is for the better IMO. Also changes
the center-point alignment of smooth mosaics for odd cell widths, but
the change is no more than half a pixel at worst and is probably an
improvement ultimately.
I've included a compatibility test here to make sure that the numbers
from this are in line with the numbers produced by xHalfs, yThirds, etc.
After this commit I'll introduce a helper function that fills based on a
span specified with this enum to replace any uses of xHalfs and friends.
Once I do that I'll remove them and the compatibility test, this should
be a much cleaner interface for this and make it easier to consistently
align block elements with each other.
Use `xHalfs` and `yHalfs` so that the dimensions of each quadrant are
appropriately aligned with block elements like the one half block, which
could be 1px taller than the bottom quadrants before this change.
This is in line with what we do for sextants, the fact that on odd-sized
cells there's a 1px overlap is considered acceptable there so I assume
it's acceptable here too.
This was creating problems with the branch drawing glyphs at some sizes.
In the future the whole "foreground modes" thing needs to be reworked,
so this is just a stopgap until that gets turned in to something nicer.
This is a fairly large rework of how we handle the sprite font drawing.
Drawing routines are now context-less, provided only a canvas and some
metrics. There is now a separate file per unicode block / PUA area.
Sprites are now drawn on canvases with an extra quarter-cell of padding
on each edge, and automatically cropped when sent to the atlas, this
allows sprites to extend past cell boundaries which makes it possible to
have, for example, diagonal box drawing characters that connect across
cell diagonals instead of being pinched in.
Most of the sprites the code is just directly ported from the old code,
but I've rewritten a handful. Moving forward, I'd like to rewrite more
of these since the way they're currently written isn't ideal.
This rework, in addition to improving the packing efficiency of sprites
on the atlas, and allowing for out-of-cell drawing, will make it a lot
easier to add new sprites in the future, since all it takes now is to
add a single function and an import (if it's a new file).
I reworked the regression/change testing to be more robust as well, it
now covers all sprite glyphs (except non-codepoint ones) and does so at
4 different sizes. Addition/removal of glyphs will no longer create diff
noise in the generated diff image, since the position in the image of
each glyph is now fixed.
There are two main improvements being made here. First, we move away from using autohash and instead
use a one-shot strategy similar to the Style hashing. Since the GlyphKey includes the Metrics struct,
which contains quite a few fields, autohash was performing expensive and unnecessary repeated updates.
The second improvement is actually just, not hashing Metrics. By ignoring the Metrics field, we can
fit the rest of the GlyphKey into a 64-bit packed struct and just return that as the hash! It
ends up being unique for each GlyphKey in renderGlyph, and is nearly a zero-cost operation.
This ends up boosting the performance (on my machine at least), from around 560fps to 590fps on the
DOOM-fire benchmark.
Forgot to change these instances when I renamed rgb(a) to bgr(a), which
was breaking test builds. Also went ahead and fixed some code that was
assuming rgba was actually rgba order and added a note to another part.
Also changes color atlas to always use an sRGB internal format so that
the texture reads automatically linearize the colors.
Renames the misleading `rgba` atlas format to `bgra`, since both
FreeType and CoreText are set up to draw color glyphs in bgra.
This should make the sorting more robust to fonts with questionable
metadata or atypical style names.
I was originally just going to change the scoring slightly to account
for fonts whose regular italic style is named "Regular Italic" - which
previously resulted in the Bold Italic or Thin Italic style being chosen
instead because they're shorter names, but I decided to do some better
inspection of the metadata and looser style name matching while I was
changing code here anyway.
Also adds a unit test to verify the sorting works correctly, though a
more comprehensive set of tests may be desirable in the future.
(Feel free to make any changes to the PR you feel necessary before
merging while I'm gone over the weekend.)
This improves "outer edge" alignment of octants and other elements drawn
using `yQuads` and friends with blocks drawn with `draw_block` -- this
should guarantee alignment along a continuous edge, but may result in a
1px overlap of opposing edges (such as a top half block followed by a
bottom half block with an odd cell height, they will both have the
center row filled).
This is very necessary since several block elements are needed to
complete the set of octants, since dedicated octant characters aren't
included when they would be redundant.
This should make the sorting more robust to fonts with questionable
metadata or atypical style names.
I was originally just going to change the scoring slightly to account
for fonts whose regular italic style is named "Regular Italic" - which
previously resulted in the Bold Italic or Thin Italic style being chosen
instead because they're shorter names, but I decided to do some better
inspection of the metadata and looser style name matching while I was
changing code here anyway.
Also adds a unit test to verify the sorting works correctly, though a
more comprehensive set of tests may be desirable in the future.
As of Zig 0.14.0, `@splat` can be used for array types, which eliminates
a lot of redundant syntax and makes things generally cleaner.
I've explicitly avoided applying this change in the renderer files for
now since it would just create rebasing conflicts in my renderer rework
branch which I'll be PR-ing pretty soon.
This commit changes a LOT of areas of the code to use decl literals
instead of redundantly referring to the type.
These changes were mostly driven by some regex searches and then manual
adjustment on a case-by-case basis.
I almost certainly missed quite a few places where decl literals could
be used, but this is a good first step in converting things, and other
instances can be addressed when they're discovered.
I tested GLFW+Metal and building the framework on macOS and tested a GTK
build on Linux, so I'm 99% sure I didn't introduce any syntax errors or
other problems with this. (fingers crossed)
Cleaner and less visual noise, easy change to make, there are many other
areas in the code which would benefit from decl literals as well, but
this is an area that benefits a lot from them and is self-contained.
Also update shaper test that fails because the run iterator can't apply
that logic since `testWriteString` doesn't do proper grpaheme clustering
so the parts are actually split across multiple cells.
Several other tests are technically incorrect for the same reason but
still pass, so I've decided not to fix them here.
We don't currently support rendering SVG glyphs so they should be
ignored when loading. Additionally, the check for whether a glyph is
colored has been simplified by just checking the pixel mode of the
rendered bitmap.
This commit also fixes a bug caused by calling the color check inside of
`renderGlyph`, which caused the bitmap to be freed creating a chance for
memory corruption and garbled glyphs.
When scaling emoji, scale so that they entirely fit within 2 cells. The
previous behavior was to scale to fill vertically, however with fonts
which are narrow this would result in horizontal overflow.
This commit is quite large because it's fairly interconnected and can't
be split up in a logical way. The main part of this commit is that alpha
blending is now always done in the Display P3 color space, and depending
on the configured `window-colorspace` colors will be converted from sRGB
or assumed to already be Display P3 colors. In addition, a config option
`text-blending` has been added which allows the user to configure linear
blending (AKA "gamma correction"). Linear alpha blending also applies to
images and makes custom shaders receive linear colors rather than sRGB.
In addition, an experimental option has been added which corrects linear
blending's tendency to make dark text look too thin and bright text look
too thick. Essentially it's a correction curve on the alpha channel that
depends on the luminance of the glyph being drawn.
This sets the stage for dynamically adjusting the sizes of fallback
fonts based on the primary font's face metrics. It also removes a lot of
unnecessary work when loading fallback fonts, since we only actually use
the metrics based on the parimary font.
This is achieved by rendering to an alpha-only context rather than a
normal single-channel context, and adjusting the brightness at which
coretext thinks it's drawing the glyph, which affects how it applies
font smoothing (which is what `font-thicken` enables).
\+ much more flexible syntax and lenient parser
\+ allows comma-separated list as a single config value
This allows, e.g. `cv01 = 2` to select the second variant of `cv01`.
Resolves#3128
Parser could probably be a little smaller than it is- would be a lot
cleaner with the labeled switch continue pattern from Zig 0.14. Maybe
should've put it in its own file too...
I spent *much* too long trying to test this with `cv01` with
[monaspace](https://github.com/githubnext/monaspace) before realizing
that the README refers to v1.2 but the latest released version (and
hence the one I had installed) was v1.101 -- I installed the v1.2
version and tested with both CoreText and HarfBuzz and successfully set
`cv01 = 2` and got the expected result.
Feel free to make any stylistic changes you feel necessary before
merging.
