You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The 20.12 split is what happens when you multiply two 26.6 fixed point values.
The 26.6 split is arbitrary, but Go's extended standard library already had a 26.6 fixed point integer type (in the golang.org/x/image/math/fixed package), so it was easy to start with that.
Since then, I've moved to 22.10 instead of 26.6 (adding some ad hoc int64 instead of int32 math) so when you multiply you get 12.20. This (and other patches) reduced some rounding errors, so that the fixed point rasterizer, when rasterizing a regular polygon, yields 0x00 pixels in the corners and an 0xff pixel in the center, all the way up to 2048 ppem. Previously, you would sometimes see a 0x01 or 0x05, say, in the corners or a 0xfe in the center, which isn't noticable to the naked eye, but is clearly incorrect.
Net some other changes, the fixed point code is still around 1.3x faster than the floating point code.
I've ported font-rs to the Go programming language.
Using fixed point math instead of floating sped up my rasterization benchmarks by between 1.2x and 1.4x.
Perhaps font-rs should do that too.
The font-go commit: google/font-go@4bf4d10
The text was updated successfully, but these errors were encountered: