tag:blogger.com,1999:blog-1272803659321539598.post1745595264499138305..comments2024-03-15T00:53:29.558-07:00Comments on Digesting Duck: Font StashMikko Mononenhttp://www.blogger.com/profile/11900996590678707801noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-1272803659321539598.post-31336821595953514802011-05-15T16:34:02.090-07:002011-05-15T16:34:02.090-07:00The following trivial patch is needed to get it ru...The following trivial patch is needed to get it running on Linux.<br /><br />https://gist.github.com/973677<br /><br />Then compile with:<br />gcc -Wall -g -o fontstash main.c fontstash.c `sdl-config --cflags --libs` -lm -lGL<br /><br />It looks sensational. Thanks!robnhttps://www.blogger.com/profile/13662060366672113059noreply@blogger.comtag:blogger.com,1999:blog-1272803659321539598.post-32160651608551006232009-09-08T02:22:28.336-07:002009-09-08T02:22:28.336-07:00I made a quick test to check the performance. I ma...I made a quick test to check the performance. I made simple allocator which always return next n bytes from a scratch buffer (in the demo the max consumption per glyph was less than 6k) so stbtt does not require any per frame allocations. I reset the buffer after every call to stbtt_MakeGlyphBitmap, and the required bitmap was also allocated from the scratch buffer. It turns out the allocations do not have much impact on the performance, but of course per frame allocations are to be avoided.<br /><br />Per glyph render times in the demo, which also includes updating the texture, vary from 0.0010 ms to 0.0400 ms. The average update time seems to be around 0.02 ms, and the very first update to a previously empty texture takes 0.1640 ms. So a _very_ unscientific estimate would bring stb_tff pretty close to ft. ymmv.Mikko Mononenhttps://www.blogger.com/profile/11900996590678707801noreply@blogger.comtag:blogger.com,1999:blog-1272803659321539598.post-8864393099841204022009-09-04T00:43:55.536-07:002009-09-04T00:43:55.536-07:00Thanks for you insights.
I have not profiled the ...Thanks for you insights.<br /><br />I have not profiled the memory usage nor speed of stb_tt yet. stb_tt allows you to plug in your own malloc, which might help a bit with the allocations. It also might be possible to do some simple analysis of the whole font to see what is the max vertex count.<br /><br />I agree that FT does better job at rendering certain glyphs. Remind me of the Apple vs. MS font rendering argument some time ago. http://www.codinghorror.com/blog/archives/000884.html<br /><br />I fell in love with the simplicity of use with stb_tt. I might take a look at the performance at some point. FontStash does somu ugly things when rendering new glyphs too, so there is definitely room for improvement there.Mikko Mononenhttps://www.blogger.com/profile/11900996590678707801noreply@blogger.comtag:blogger.com,1999:blog-1272803659321539598.post-83987907127350217312009-09-03T15:52:34.633-07:002009-09-03T15:52:34.633-07:00I recently tried switching in STBTT in place of Fr...I recently tried switching in STBTT in place of FreeType in the hopes that it would be faster and more friendly to dynamic allocations. Unfortunately I found that its rasterizer is about 3x slower than FreeType's. Depending on the usage scenario this may or may not matter but it certainly makes dynamic glyph caching more difficult.<br /><br />A font with about 350 glyphs takes about 8ms to rasterize at size 14 in FreeType and 26ms in STBTT.... thats more than the budget for an entire frame!<br /><br />On the memory front it seems it has to do a dynamic allocation for each glyph when fetching its vertices. Although this can probably be hacked around such that it uses a fixed size scratch buffer for this. I don't know about FreeType yet, never got around to hacking it so I can easily trap its allocations (wouldn't surprise me if FT is worse). I suspect STBTT wins here, or at least can easily be tweaked to win. I believe if I can fix this allocation for vertices STBTT would run without allocating any of its own memory.<br /><br />Quality wise it appears FT is a bit better, specially on smaller fonts when doing a side-by-side comparison. Some strange artifacts on a few characters, some extra aliasing and on really thin characters the anti-aliasing tends to make some characters 50% transparent vs FT which still manages to keep them opaque.<br /><br />Overall STBTT is certainly interesting, and I like that its easy to build into a project vs freetype. Right now I have them both built into my tools chain so I can switch back and forth so I can keep track of its progress but for now I have to stick to FT.James Dolanhttps://www.blogger.com/profile/14788855313245104425noreply@blogger.com