4 ms·
It does the moment your user starts to zoom rapidly in and out Well yes, that'll wipe out the cache hit rate, but when has the use case of 'zooming rapidly in
by joosters 11y ago
It does the moment your user starts to zoom rapidly in and out
Well yes, that'll wipe out the cache hit rate, but when has the use case of 'zooming rapidly in and out of text' ever been a particular point on contention for any application? Even the original iphone's web zoom was good enough, a smooth zoom with temporarily blurry text until you pick a good zoom point. Seems like a very obscure niche functionality to optimise, one where no-one apparently cares about right now.
I'm an old enough fart myself to know that at least the earliest ARMs with RiscOS (as well as the Amiga's) had little enough memory/cpu bandwidth to make fast, smooth zooming of lots of text a challenge even with pre-cached font-bitmaps.
True enough! I can't even think of any app that had smooth zooming... most apps had a zoom factor (e.g. x1, x2, etc) that would work perfectly with a font cache. The main crunch point was the simple, intelligent, partial rendering of text as you pan around a page.
At small sizes you obviously can easily afford to cache, but then you end up having many more small blits
Going back to my nostalgia for RiscOS, I wrote a dumb anti-aliased font renderer that would draw fonts dot-by-dot rather than by blitting a 2d transparent bitmap to the screen, it turned out to be massively faster than even a simple cached bitmap font renderer, even at larger sizes. Definitely not a good approach today with higher-res screens though... (and the storage format was massively wasteful at larger sizes)
Terminal text rendering is a bone of contention for me, as it's frustrating how some modern-day terminals can be utterly appalling at doing their job (e.g. typing 'dmesg' and having to wait several seconds for it to complete), so I'm all in favour of anyone who takes an interest in making it fast. Most terminals unfortunately seem to try and redraw every new line to the screen, rather than realising that they've got another 10000 lines to print and perhaps the user might be content with a (say) 30fps update interval...