Basic idea is to use "A intersect B" to get convex corners and "not(C intersect D)" to get concave; that guy simplified to median(A,B,C).
-
-
Replying to @nothings
Hmm! For fonts, only handling axis-aligned corners seems OK. With 4 channels, ought to be able to cover both cases. Median feels wrong.
1 reply 0 retweets 0 likes -
Replying to @iainmerrick
Can believe the median thing is possible, just not clear how to generate ANY variant robustly, e.g. if corner is near another segment.
4 replies 0 retweets 0 likes -
Replying to @nothings
It’s frustrating because SDF text is *so close* to being a perfect replacement for all text rendering
3 replies 0 retweets 1 like -
Replying to @iainmerrick @nothings
SDFs are too slow to generate when you are downloading the fonts on the fly (web browsers).
1 reply 0 retweets 1 like -
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 -
Replying to @pcwalton @iainmerrick
I meant 100ms for the whole font once, but yeah.
1 reply 0 retweets 0 likes -
Does a typical web page use more than 500 unique scale-independent glyphs? You're budgeting 1ms if that quantity.
1 reply 0 retweets 0 likes
That’d probably be fast enough, but a regression over current state. Anyway, we can’t ship SDFs due to quality issues in the first place.
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.