Optimize text rendering

[kazcw]

The IDE is spending more than a quarter of its CPU time in the redraw_line function. Any efficiency improvement in this function could have a large impact on frontend performance.

[kazcw]

Of the redraw_line time during startup, 60% is in 2000 calls to new_glyph, and 40% is in 90 calls to shape_line.

[kazcw]

new_glyph is setting up FRP networks; shape_line spends all its time in msdf calls. No easy gains here. I've added profiling to the relevant functions, so that it'll be easy to see in profile data where we're spending the time here.

[enso-bot]

Keziah Wesley reports a new STANDUP for yesterday (2023-02-16):

Progress: Profiled text rendering; unfortunately, not much room for improvement. Investigated dropdown creation, and identified a possible optimization. It should be finished by 2023-02-16.

Next Day: Next day I will be working on the #5671 task. Optimize dropdown creation.

[wdanilo]

Of the redraw_line time during startup, 60% is in 2000 calls to new_glyph, and 40% is in 90 calls to shape_line.

Thanks for such a clear breakdown of what happens there!

new_glyph is setting up FRP networks; shape_line spends all its time in msdf calls. No easy gains here. I've added profiling to the relevant functions, so that it'll be easy to see in profile data where we're spending the time here. If we are calling it so often, maybe there is something broken with our discovery of which glyphs are already cached. Another possible optimization for startup is pre-caching of all ASCII glyphs and bundling them with app, but TBH, we can live with the first glyph caching if this is not happening after the glyphs are already cached.

This is surprising. We are using MSDF only to generate new glyphs, so if a glyph was already created, we should not even call these functions. Taking into consideration we are not using many glyphs, this should not be called often.

Regarding new_glyph, I understand that the conclusion is that the FRP setup is just slow there, right?

[wdanilo]

@kazcw I'm reopening it as I don't think we solved it - or did you close it on purpose?

[kazcw]

MSDF Calls

Cost: 0.5s loading Orders, scales sublinearly with number of glyphs

The cache is working. We're loading 73 glyphs to draw Orders, never the same TTF GlyphId twice. The msdf functions are taking a lot of time per glyph. This is largely because the floating-point math is 4x as costly without SIMD (#5723); however, we can eliminate the runtime work entirely by bundling a pre-computed atlas (#5722), and that's probably the most expedient solution.

FRP Setup in new_glyph

Cost: 0.8s loading Orders, scales linearly with number of glyphs

Status: We set up FRP networks for 2000 glyphs to display Orders, and more to open widgets. Since the cost scales linearly, that's a big problem.

Potential optimizations:

• ?? improvement: Speed up FRP network creation? We could implement deep-copying for FRP networks (returning a new network that doesn't share identity with the origin network), and then spawn all glyphs by deep-copying a prototype glyph. I would need to look in to this further to estimate how much time it would save, and how much work it would take.
• ~10x improvement: Use fewer FRP networks? I would expect an order of magnitude improvement if we only created FRP entities per span rather than per glyph, but this would be a complex change.
• Eliminate Glyph FRP Network #5724

[wdanilo]

@kazcw we can easily eliminate FRP from Glyphs. There are several things to be done here:

1. FRP set_color can be changed to just a function.
2. FRP target_color can be converted to variable in glyph.
3. The color animation can be removed from glyphs (sure, worse effect, but big improvement of removing FRP).
4. The FRP network with the title === Debug mode === is used for debug purposes only. Let's remove it for now. We can code it different way around in our debug scene.

This way you can remove FRP completely from Glyphs. Let's do it. Also, if you could try fixing the text-area debug scene then, it would be cool. This is the only scene that was using these FRP debug bindings.

[kazcw]

Closing this because I've finished the investigation, and each optimization has its own issue.