Click here to Skip to main content
16,022,069 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I'm caching fonts using a primitive LRU system I came up with, but something is behaving funny.

core2_flex_font/include/flex_font.hpp at main · codewitch-honey-crisis/core2_flex_font · GitHub[^]
core2_flex_font/src/flex_font.cpp at main · codewitch-honey-crisis/core2_flex_font · GitHub[^]

Without caching I get
32 FPS for 16-bit Windows raster fonts - which is about the max for that display
9 FPS for Truetype

With caching I get
32 FPS for 16-bit windows raster fonts
22 FPS for Truetype.

I should note that this is an embedded device running an RTOS, so it behaves consistently every time. Makes benchmarking easy.

What's curious about this caching, is I have two callbacks on my fonts
on_measure
and
on_draw

when I use the cache, it doesn't trigger those callbacks on a cache hit.

The callbacks are what take the time, for most fonts, especially those with kerning table lookups and vectors, like Truetype.

Since the draw routine and measure routine are a common base of all font classes, the caching code is exactly the same code.

In my tests reported from above the cache is big enough to hold everything without expiring items, and I've verified that no expirations are happening.

I'm expecting - once cache hits start happening - for the performance to be consistent regardless of the type of font since it's not even calling the font specific overrides anymore

What I have tried:

I verified that it's caching everything. I'm always getting cache hits after the first time.

I thought maybe my buckets were unbalanced but that doesn't explain the discrepancy in frame rates either, because they'd be unbalanced for all of the fonts. It's the same caching code, configured the same way.

It's not memory, because again, I'm still getting cache hits every time.

My cache doesn't create items on its own, so it's not calling some create function spuriously.

I don't know what else to try. I need some ideas here.
Posted
Updated 14-Aug-24 8:35am
v2

1 solution

I found a solution, but it's not easy to explain, and I was overconcerned about fragmentation since my caches don't need that much memory in practice. 8-16KB on the large side of things in most circumstances.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900