Tiny TTF should be caching stbtt_FindGlyphIndex about lvgl HOT 26 CLOSED

My hack was entirely containing cache lookup to a small internally held table, no hash lookups - so I can't comment how much faster or slower it is compared to cache system lookup call, and would only probably be viable for a reasonably small latin like glyph set, the ttf fonts we're using have < 200 glyphs included after being stripped for size, so a lookup table seemed reasonable compromise for quickness of implementation, and for at least one busy text screen ( several hundred chars ), my whole lvgl rendering cycle appeared to go from 280ms to 8ms

from lvgl.

I can confirm it really really hurts current performance, I've not had time to go back and try to do a 'real' cache implementation, but I quickly hacked a sufficient array table based one for our font usage into project and it increased performance well over an order of magnitude for a busy text screen. The quick hack I did was mentioned in one of the lvgl 9 closed cache threads the other day ( #4835 ), and a suggestion was given there to use details from freetype implementation into tiny ttf to properly use the inbuilt cache routines for the cache. I may go back to this later once current critical phase of project is done, but for now it works well enough for us that I don't have time. I did also add a table clear if font size is chanced in addition to the mentioned there, but our solution is not suitable as a library pull for sure.

from lvgl.

Thanks for you feedback. I'm the original contributor of this library which I adapted from some public domain code for game engines :), and I implemented the cache quickly as it was a requirement for LVGL. I need to do some legwork if I was to upgrade this code, because I do not yet fully understand the LVGL cache system yet. I learned just enough of it to be dangerous.

from lvgl.

With the additional quick 'n dirty cacheing in place, it now works pretty well for us, difference in speed vs plain bitmap fonts is negligible now, at least in environment with plenty enough RAM to cache everything - I did also increase the max amount of elements allowed into the cache quite a bit, though I haven't tried to verify how much difference that made.

from lvgl.

I appreciate this. It's all very helpful. I'll tinker with the caching once I solve some unrelated issues I'm having with the new LVGL 9+

from lvgl.

Actually Gabor, I found it now. I just had to look further in the source than I was looking. Thanks anyway.

@kisvegabor can I get some guidance on using the cache? I'm not clear on how the search key is used below:

const lv_font_t * font = g_dsc->resolved_font;
tiny_ttf_cache_data_t search_key = {
    .font = (lv_font_t *)font,
    .unicode = unicode_letter,
    .size = font->line_height,
    //.glyph_index
    //.draw_buf
};

I've added glyph_index. Like draw_buf it's to be fetched FROM the cache, not used to search for the data. Does that make sense? How does lv_cache_acquire_or_create(tiny_ttf_cache, &search_key, (void *)font->dsc); know to leave draw_buf out of the search criteria? I need the same for glyph_index.

from lvgl.

I tried caching the glyph indices but it turns out the LVGL cache system is slower than stbtt_FindGlyphIndex. In any case, the latest bits are much faster than 9.1 release so I'm happy.

from lvgl.

I tried caching the glyph indices but it turns out the LVGL cache system is slower than stbtt_FindGlyphIndex. In any case, the latest bits are much faster than 9.1 release so I'm happy.

So, is there no longer a need to add a cache for glyph index?

But @MacDragon said that the performance has improved a lot.

from lvgl.

@MacDragon which version of LVGL?

from lvgl.

9.1

from lvgl.

The latest bits in the master branch are much faster, in my experience. After looking at it, someone changed the cache code to eliminate the call to FindGlyphIndex inside the rendering routine. That improved performance pretty dramatically.

from lvgl.

Interesting, preferences is generally to stick on a 'release' version, so haven't tried raw master branch.

from lvgl.

I totally get it. I'm just putting it out there so you know once the next version is rolled out, those perf improvements have been made. :)

from lvgl.

Good to know certainly, will bear in mind whenever next release is.

from lvgl.

The latest bits in the master branch are much faster, in my experience. After looking at it, someone changed the cache code to eliminate the call to FindGlyphIndex inside the rendering routine. That improved performance pretty dramatically.

Wow, that sounds great. Could you please tell me where this code is?

from lvgl.

src/libs/tiny_ttf/tiny_ttf.c (give or take, it's from memory)

I'm not sure it can be retrofitted to earlier versions, as I am half sure the generalized caching system has evolved since 9.1

from lvgl.

src/libs/tiny_ttf/tiny_ttf.c (give or take, it's from memory)

I'm not sure it can be retrofitted to earlier versions, as I am half sure the generalized caching system has evolved since 9.1

OK fine

As far as the information I know now is concerned, tiny_ttf adds the cache generated by bitmap.

Generally speaking, what we are looking forward to is

1. unicode -> glyph_index
2. glyph_index -> bitmap

Two-level cache, but at present, there is only glyph_index -> bitmap cache now.

@MacDragon describes the addition of a glyph_index cache.

I don't seem to find this related cache.

By the way, it's I modified the cache of bitmap, so I'm quite concerned about this issue. 😁

from lvgl.

I want to confirm that if some optimizations have been made on the tiny_ttf library itself, resulting in the acceleration of GetGlyphIndex, then I don't need to modify it further.

If not, I can add the cache of unicode -> glyph_index.

from lvgl.

There isn't a two level cache. The reason being is I tried implementing a two level cache using the generalized caching system. My tests found that stbtt_FindGlyphIndex is usually or always faster than a cache lookup. Now, when caching entire renders as bitmaps, it pays for itself, but just caching letters->glyph_indexes for a font does not.

It may be possible to do what MacDragon is doing and implement your own cache. I've decided not to do that after considering it because the renders are already quite quick now that the bitmap cache also caches the glyph_index, coupled with the fact that going "off book" and sidestepping LVGL's cache and its management infrastructure left a bad taste in my mouth. It would require at best, a whole separate set of config #defines just to hammer out how much cache to give it. And that's best case scenario, and not accounting for the added flash footprint, maintenance, and testing. It just doesn't seem worth it given current performance. Have you tried the latest bits?

from lvgl.

Yes, I did note in my post in other thread about the hacky implementation that I wouldn't consider something like it for a pull either, it as mostly noting that there was maybe potential, but if how labels are rendered has changed it may be less necessary.

from lvgl.

After what I tried, I'm thinking that too. Your "hacky" implementation is probably faster than the generalized cache, but the extra churn in maintaining a separate cache (in terms of runtime overhead, extra complication of config, flash space and labor) is simply not worth it I think. It's quite fast now in my tests. I think in general it's a great idea to find out if you need to optimize before you optimize, which is why I asked W-Mai about trying the latest bits.

from lvgl.

You know what would be interesting? If LVGL cached the actual metrics fetching call results of any and all fonts, instead of calling the metrics callback over and over. Caching the width, height and advance by unicode letter and font. I'd have to remove the set_font_size call in tiny ttf because it would break the cache, but in general it might sidestep this issue, and pay for itself. @kisvegabor , your thoughts on this?

ETA: I'm off to bed for now. I'll pick this back up where we left off when I can.

from lvgl.

@codewitch-honey-crisis You can take a look on the implementation of lv_freetype. In the implementation of freetype, the use of cache is very suitable, using two-level cache, which improves a lot of efficiency.

from lvgl.

freetype also takes gobs of ram. TinyTTF doesn't, which is kind of the point of it,

from lvgl.

Did you even use the latest bits? I'm not putting in two-level cache.

from lvgl.

Did you even use the latest bits? I'm not putting in two-level cache.

I know that, that's what I wrote, the draw_buf cache, lying in the latest bits.

But I think we can add a new unicode -> glyph_dsc will speed up the process.

Please take a look at, here is the code what I'm mentioned 😁

• #6333

from lvgl.