Good question. I don’t have any authored SDF content right now so take this with a grain of salt, but my thoughts are:
1. Fonts are a very small percent of most games’ storage and frame time, so there’s less motivation to compress them than other textures
2. Every pixel in a font is pretty intentional (unlike in, say, a brick texture) so I’d be hesitant to do anything lossy to it
I suspect that a single channel SDF for something like a UI shape would compress decently, but you could also just store it at a lower resolution instead since it’s a SDF. For SDF fonts I’d probably put them through the same asset pipeline but turn off the compression.
(Of course, if you try it out and find that in practice they look better compressed than downscaled, then you may as well go for it!)
[EDIT] a slightly higher level answer—you probably wouldn’t compress them, but you’d probably still use this workflow to go from my_font.ttf -> my_font_sdf.ktx2 or such.
Tangential: where does pixel art textures fall under in this consideration for asset compression?
That’s also a good question.
I personally wouldn’t compress pixel art—the artist presumably placed each pixel pretty intentionally so I wouldn’t wanna do anything to mess with that. By pixel art’s nature it’s gonna be low resolution anyway, so storage and sample time are unlikely to be a concern.
Pixel art is also a special case in that it’s very unlikely you need to do a bake step where you downsize or generate mipmaps or such. As a result, using an interchange format here could actually be reasonable.
If I was shipping a pixel art title I’d probably decide based on load times. If the game loads instantly with whichever approach you implement first then it doesn’t matter. If it’s taking time to load the textures, then I’d check which approach loads faster. It’s not obvious a priori which that would be without measuring—it depends on whether the bottleneck is decoding or reading from the filesystem.
Makes sense, thanks for the insight.