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.
+ 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`.
macOS bitmap-only fonts are a poorly documented format, which are often
distributed as `.dfont` or `.dfon` files. They use a 'bhed' table in
place of the usual 'head', but the table format is byte-identical, so
enabling the use of bitmap-only fonts only requires us to properly fetch
this table while calculating metrics.
ref: https://fontforge.org/docs/techref/bitmaponlysfnt.html
Reverts #3550 for obvious reasons, and may close issue #2168 because
this should now mean that bitmap fonts are properly supported under both
font backends due to #3837 - unless `otb` fonts are still not properly
supported under FreeType (they are not supported under CoreText because
CoreText does not know how to handle them).
I tested this change with the `.dfont` distribution of
[Cozette](https://github.com/slavfox/Cozette) v1.25.2 and saw no visual
issues.
macOS bitmap-only fonts are a poorly documented format, which are often
distributed as `.dfont` or `.dfon` files. They use a 'bhed' table in
place of the usual 'head', but the table format is byte-identical, so
enabling the use of bitmap-only fonts only requires us to properly fetch
this table while calculating metrics.
ref: https://fontforge.org/docs/techref/bitmaponlysfnt.html
The original version had issues converting properly and caused broken
glyphs. This version tries to be as simple as possible in order to make
it easy to understand. I haven't measured the performance but in
practice this will only happen during the first render of the glyph
after a face change (i.e. during launch or when changing font size).
We do not currently support bitmap fonts in a real capacity, and they
often are missing some tables which we currently rely on for metrics,
and we don't handle the metrics calculations failing gracefully right
now.
Annotate the node count of all uses of z2d `StaticPath` to verify
correctness, adjusted the size of a couple which were oversized, and
changed all painter calls that take node slices from `StaticPath`s to
use the slice from the wrapped `ArrayList` so that we don't include any
potentially `undefined` nodes at the end of the list, which I think was
causing a crash before.
Introduces static path methods and a reworked context API that makes
things generally cleaner.
This update incidentally fixed a bug we had before where the corner
triangle shade characters were drawn solid rather than medium shade.
Subsumes #2580 (which has multiple conflicts with main due to recent
changes to metrics); I figured it'd be easier to just implement it this
way.
#2580 claimed to solve #2487 but I don't think it really does- ideally
we can think of a good way to configure each individual cursor type, but
I don't wanna just do something ad hoc and add a bunch of config keys
blindly so I limited the scope of this.
Unicode 16 added "Separated Block Quadrants" from CP 0x0x1CC21 through
0x1CC2F:
To test, use the following command:
```
printf "\U0001CC21\U0001CC22\U0001CC23\U0001CC24\U0001CC25\U0001CC26\U0001CC27\U0001CC28\U0001CC29\U0001CC2A\U0001CC2B\U0001CC2C\U0001CC2D\U0001CC2E\U0001CC2F\n"
```
Which should look like this:
cc @qwerasd205 @rockorager
