RandyGaul
Animating cf_push_front_size causes rasterization
There will always be a noticeable on-demand "hitch" if the user is rendering a lot of text and it changes size enough to trigger a rasterization. This can happen no matter what kind of fancy caching/lerping might go on to reduce rasterization.
Instead, the API should have a thorough redesign so it's very difficult to trigger a rasterization from size changing. Somehow specifying expected sizes up-front, or, perhaps funneling size changes through a local glyph scaling. Not sure, it's a fairly tricky API design problem for now.
I think local glyph scaling down is fine from a higher res subtexture but going the other way would look pixelated. Would the funneling size changes go down by taking the largest glyph size and removing the smaller ones from the atlas?
Hmm, I think we may just want to let users decide how to do scaling vs rasterizing, and the API needs to express those differences. The big issue here is that push/pop functions are all designed to be called 1000x per frame without a perf impact. So we can't have the raster API use the same design.
We don't need do to any super fancy auto-scaling thing.