Hi @ngxson. Can you elaborate more why reading font files from the SD card (Like #455, for example) is too slow?
Thanks.

@Uri-Tauber I haven't tested the mentioned PR, but it should be pretty understandable why SD card can be slow.

Each time you read even a small byte from SD, the program actually does:

• Call to the FAT file system
• The FAT file system figure out where is the block
• It sends a read command to SD card
• SD card controller process it, search for the block (1 block = 512 bytes), then respond
• Read data is copied back into RAM

It is common knowledge that SD card is not optimized for random read/write.

My implementation rely on mmap which is backed by ESP32's MMU, it has the same performance as accessing random data inside the firmware.

@ngxson if I’m not mistaken, #455 implements an LRU (Least Recently Used) cache. Since most books are written in a single language (two at most), we can reasonably assume that — for example, as in real @ruby-builds sets it to 30 — having 128 distinct characters is sufficient to render an entire book.

If we assume each character is a 1-bit 16×16 pixel grid, the total cache size would be about 16 KB.

On the other hand, while your implementation is more memory-efficient, it makes things harder for the average user who just wants to add their favorite fonts and doesn’t know — and doesn’t want to know — anything about manual flashing.

On the other hand, while your implementation is more memory-efficient, it makes things harder for the average user who just wants to add their favorite fonts and doesn’t know — and doesn’t want to know — anything about manual flashing.

I assume you haven't fully read my OP:

The expected user flow will be:
1. The project can provide a list of pre-made resources, similar to https://amazfitbip.ngxson.com
2. User choose the resources to be packed, and download it to SD card (file name: resources.bin)
3. Upon boot, resource will automatically be flashed

having 128 distinct characters is sufficient to render an entire book.

It's clearly not sufficient at least in my native language, vietnamese. I imagine it will get worse with japanese for example, where the number of grapheme is massive even when compared to chinese

edit: hmm, probably a bad example because all vietnamese and japanese usually has a quite high number of repeatedly used grapheme. I guess this only affect chinese

@ngxson Sorry. I missed that.

I'm not very familiar with Chinese, but from a quick search, it looks like there are over 20,000 glyphs just in the CJK Unified Ideographs block of Unicode (U+4E00–U+9FFF). How would your approach handle this? Using two or three fonts could easily fill up the entire flash.

The CJK block covers multiple Asian languages (and even covers obsolete one like Chu Nom). In practice, a human never use the whole CJK, so it will make more sense to separate it by language.

In my experience, most memory-constraint system either support chinese+english, japanese+eng combinations, or easten-only language, I never seen one that support both chinese(simplified) and japanese at the same time.

But yes this may worth considering. I haven't looked specifically into japanese but I think it can be hard to fit the whole katakana+harigana+kanji into flash, it's basically massive. That can be the only blocking point for my approach

edit: in practice, katakana and harigana are pretty small, around 200 graphemes. I've done my research and concluded that ~6000 graphemes are needed to cover japanese's kanji

After some more consideration, I think my approach is not good as-is. While it works on some other memory-constraint devices, it mostly because they don't have access to a sdcard.

Serving fonts from sdcard has some performance issues as discussed, but I think it worth the trade-off because we don't usually render too many texts at once anyway.

I'm closing this PR as I don't plan to continue it. Will focus my efforts on other parts of the project.