Tiny TTF lib: lv_tiny_ttf_set_size() should be removed or clear the cache

[codewitch-honey-crisis]

LVGL version

9.1

What happened?

If you set the size of the font using the lv_tiny_ttf_set_size(...) routine it does not clear the glyph cache. This could lead to stale caches of the bitmaps at the wrong size.

It should either be removed, or it should clear the cache

How to reproduce?

No response

[kisvegabor]

Thanks! Mentioned in #6333

[W-Mai]

Let me open a new pr to remove this

[MacDragon]

I added a glyph/bitmap cache delete and recreate on resize in my cacheing modifications, though I didn't get around to testing it - kern caching not removed as this is not size dependant.

[codewitch-honey-crisis]

I made a little performance tester for a TTGO T1 Display since they're so common. It works under Arduino or the ESP-IDF To use it, copy the root of the latest branch into libs/ and upload w/ Platform IO https://github.com/codewitch-honey-crisis/tiny_ttf_improvements

Results - 6/1 build - 187 iterations per second under Arduino! (i think the caching was flawed). 18 under the ESP-IDF Results 6/14 build 30 iterations per second under Arduino, 30 under the ESP-IDF.

So discounting the 187 iterations result, it looks like an improvement from 18 to 30, cautiously.

I'd be happy to test the latest branch whenever it's committed.

[MacDragon]

The forked branch linked on my GH in the main cacheing thread ( https://github.com/MacDragon/lvgl/tree/🐻 ) has where I left it at currently committed 10 hours ago, not sure if that's what tested, and appeared to be working pretty well for me - comparing kerning on and off times would be useful too, assuming working with a font that has kerning tables it can actually use. the font kerning flag gets turned off if unusable table found. For testing I was using win 3.1 release arial font, grabbed from https://github.com/pjobson/Microsoft-Fonts/tree/main/1992%20-%20Windows%203.1 , as the kerning tables worked properly there.

[codewitch-honey-crisis]

I'm getting weird results with your forked branch. Once again Arduino is about 10 times as fast as the IDF. I'm no longer going to discount that.

Arduino - 1010 iterations per second. ESP-IDF 104 iterations per second.

Either way, that's a significant improvement but I'm confused about the results.

[MacDragon]

A difference that big I'd have thought could be true hw floating point vs software or something?

[codewitch-honey-crisis]

That doesn't track because 90% of the code is identical between the platforms. There are only minor differences in main.cpp to support both platforms. I'm getting what looks like correct results on the screen and it IS visibly faster under Arduino, but so fast i can't really see the scrolling that well. I've had some weird performance anomalies like this before with Arduino. Sometimes faster, sometimes slower than the IDF, but usually by a factor of 2, not 10. Something's afoot. Worst case, something isn't marked volatile that should be, as the IDF is much more sensitive IME. Edit: I need to investigate something i just thought of. Edit 2: No dice. Still getting weird results. I'm stumped. At least the output looks right from what i can tell.

[codewitch-honey-crisis]

Your comment made me think of something. On the ESP32 the FPU can only run on the 1st core that it's accessed from. Arduino and the ESP-IDF are set up differently in terms of allocating tasks and such. It MIGHT be possible that the ESP-IDF is having to thunk from the 2nd core to the 1st one to access the FPU (or maybe it reverts to software on the other core, I'm not sure). Edit: Either way, the results look okay, so I think if we have a good way of testing your work it should be fine.

[MacDragon]

That sounds plausible maybe, not sure which behaviour sounds more likely but if it's fpu I'd think would have to be full software va hardware to be anything like that factor, but yes, as far as I can see the performance increase is definitely quite credible now, though would be interesting to see how different kerning pair cache sizes effect things when theres a lot of changing text.

[codewitch-honey-crisis]

I've largely fixed the performance issues under the IDF. It was my ignorance of the IDF that was most of it. :) Live and learn.

It's up to 940 iterations per second which puts it within the ballpark accounting for platform differences

[MacDragon]

good to hear - I've not got a really 'low' power platform with a screen readily available, I've got a few pi2040's and such, but no screens - though I guess nothing would stop testing the theoretical rendering and just dumping the flush to get some timings.

[codewitch-honey-crisis]

Honestly, I can't recommend the TTGO T1 Display enough for this kind of thing. Integrated screen, two buttons. Relatively inexpensive. It's my workhorse for this sort of thing.

[W-Mai]

The forked branch linked on my GH in the main cacheing thread ( https://github.com/MacDragon/lvgl/tree/🐻 ) has where I left it at currently committed 10 hours ago, not sure if that's what tested, and appeared to be working pretty well for me - comparing kerning on and off times would be useful too, assuming working with a font that has kerning tables it can actually use. the font kerning flag gets turned off if unusable table found. For testing I was using win 3.1 release arial font, grabbed from https://github.com/pjobson/Microsoft-Fonts/tree/main/1992%20-%20Windows%203.1 , as the kerning tables worked properly there.

Grand masterpiece! 👍

[lvgl-bot]

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

[kisvegabor]

Let's continue in https://github.com/lvgl/lvgl/pull/6441