OSD tab is relatively slow to load (most time spent in font load/parse)

[DavidAnson]

Describe the bug

1. Load the OSD tab using virtual connection on a slowish computer (Chromebook)

Profiling shows about 1.7s of total time is spent handling the font download, about 0.9s of which is self time in toDataUrl: https://github.com/betaflight/betaflight-configurator/blob/1809bb8f92db749e8dc466868d2e8ee519c2d25c/src/js/tabs/osd.js#L3507

It looks like the code parses the font file characters and then calls pushChar for all of them and that function ends by calling draw for every character which force-renders them (and also caches them): https://github.com/betaflight/betaflight-configurator/blob/1809bb8f92db749e8dc466868d2e8ee519c2d25c/src/js/tabs/osd.js#L133

I can't easily stub this out to try, but it seems to me that the artificial call to draw from pushChar is unnecessary and could be removed which would wait to render each character until it was needed (many of which won't be needed at all) and would still be cached.

To Reproduce

See above

Expected behavior

Faster, please :)

Configurator version

11.0.0 (1809bb8)

Flight controller configuration

Add any other context about the problem that you think might be relevant here

N/A

[DavidAnson]

Okay, good news, good news, bad news, comment, idea:

1. I tried this.
2. It reduces OSD tab load time from a mental count of 3 seconds to about 1-1.5 seconds (i.e., cuts to 30-50% of current).
3. It breaks rendering of every character in Font Manager (not the OSD display, just Font Manager).
4. I don't see why this should need to be broken, but am not spending more time right now. I observe that drawCanvas seems to have some straightforward optimization opportunities.
5. Does each character really NEED to be a data: URL of a rendered bitmap of a canvas? What about building an SVG instead?

[DavidAnson]

Okay, I got something working and sent a PR. I don't love what I did and I'm fine if you all don't want to take this change since it's not as much of an issue on a good computer.

[DavidAnson]

The more I think about this, the more I think using an SVG instead of rendering to a canvas would be a better approach. If that's fast enough, the changes in my linked PR could be rejected because the current "render everything during initialization" implementation would be good enough. I don't have time to prototype that tonight, but I might try it tomorrow since this has caught my attention. (Don't worry, I haven't forgotten about the modal dialog change - I did a bit of work on that last night. :) )

[haslinghuis]

IMO this is a big improvement as people spend a lot more time on the OSD tab than users who use the font manager. The mcm files are used in foreign tools so not sure about using SVG.

[DavidAnson]

Thanks! I don't understand your comment about MCM and SVG, but maybe it will be clear once I try to do it.

To be clear, I'm not proposing to change the data in the MCM files at all, just to change the representation of the character bitmaps. See the link below for what I mean. If I'm right, the only change should be to the draw Canvas function and everything else will work just like it is now.

Or I might be wrong... :)

https://css-tricks.com/lodge/svg/09-svg-data-uris/

[DavidAnson]

@haslinghuis, what's the thinking here? There are two PRs that address parts of this issue. I feel relatively confident in the SVG one #4497 and semi-confident in the deferred loading one #4495. My proposal would be to review and accept the SVG change if it looks okay and probably stop there for now. The defer change could also be applied, but I feel that it has broader reach and I don't know the surrounding code super well.

[haslinghuis]

@DavidAnson can we close this as solved in #4497 ?

[DavidAnson]

@haslinghuis, I agree that makes sense!

[haslinghuis]

• fixed in #4497