SDFs are too slow to generate when you are downloading the fonts on the fly (web browsers).
-
-
Replying to @pcwalton @iainmerrick
I think if the stb_truetype SDF generator were optimized in obvious scanline ways (currently every pixel is independent) it'd be ok.
1 reply 0 retweets 0 likes -
I mean, I guess when you're aiming for sub-100ms full render times so you can't spare 100ms for SDF maybe not.
1 reply 0 retweets 0 likes -
Replying to @nothings @iainmerrick
100ms is way too slow. I need 2µs per glyph or so.
2 replies 0 retweets 1 like -
I view SDFs mostly as a lossy compression technique for storing large CPU rasterized glyphs on GPU, not as a vector format at all.
1 reply 0 retweets 1 like -
Replying to @pcwalton @iainmerrick
That's not a use case I think of SDF being for at all. Use a 2-3bpp bitmap for that.
1 reply 0 retweets 0 likes -
Replying to @nothings @iainmerrick
Point being you have to essentially rasterize the glyph first to generate an SDF.
1 reply 0 retweets 0 likes -
Replying to @pcwalton @iainmerrick
Yes, if you're only going to use the SDF once before turning it into a bitmap, there's no point in using SDF.
1 reply 0 retweets 0 likes -
If you're going to do it more than once, then you can pay that cost once and leverage it in faster rerendering at other scales/subpixel pos.
2 replies 0 retweets 0 likes -
Replying to @nothings @iainmerrick
I’ve found that tessellation ends up faster for that case, if you defer Bezier sampling to vertex shaders. Tess shaders are even better.
2 replies 0 retweets 2 likes
Since you can tessellate a path of n vertices in O(n log n) with trapezoidation algorithm. My current area of work :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.