Honestly I havent done anything.
But here is what I would do (Pseudocode):
Modify LV_FONT_DECLARE to do 2 additional things:
- set the user_data of the font to the font name and pt size, so it would be somewhat unique. So like roboto16 or whatever
- Store the font name and a pointer to the fonts in a global location so it can be accessed. I have only made a cursory glance at the code to find a proper location of this, but maybe in lv_font.c
So the use case is:
Saving/Deserializing an object that references a font:
That would essentially get the user_data for the font name
Serializing or loading an object:
lv_font_t *font=get_font(char *fontName)
This would do a lookup of the font table and get return a pointer to the font (or a reference, dealer’s choice), or if it is not there, return the default font.
This keeps objects separate from fonts as the architecture is currently, but provides a linkage if needed.
So here is my thoughts on mem/cpu usage:
Mem - Each font would have its name+pt size attached to it, either as user_data or as part of lv_font_t (I actually like the latter better, as end users might need user_data and could stomp on it).
This should be < 20 bytes per font, assuming a name < 18 bytes and a 2 byte pt size
We would also have the same memory duplicated in the map.
This would be a hashmap or a linked list that we walk on deserialization (Not a big hit, since there will be few fonts, and this is only done once per object)
So we would have a struct essentially of: