30% slowdown (in everyday page rendering) for 15% space reduction doesn't sound like a good trade off. We should rather move fonts to SPIFFS.

Instead of caching, maybe consider only compressing rare glyphs?

Is there any way to have font files on the SD card and then put into flash when they are selected in the settings? This would allow us to have more fonts/sizes.

Agree with Jonas, page change responsivity is the main "feature" of an e-reader, it trumps more fonts for sure. If you feel this is a "must-have", perhaps it's possible to consider creating a "light" version of Crosspoint with limited font choices for people who prioritize responsiveness?

Is there any way to have font files on the SD card and then put into flash when they are selected in the settings? This would allow us to have more fonts/sizes.

We will do that after 1.0 when we are ready to ditch the stock os (and hence can overwrite the SPIFFS partition of the embedded flag with font cache data loaded from SD card)

Yeah agree that the current tradeoff is not yet worth merging this, unless that time cost gets quite low this isn't a valid path. I mostly put it together to experiment with the idea.

"rare glyphs" is a bit of an interesting one as it's likely language dependent, for example for my books all Cyrillic glyphs are "rare", and for others, other sets will be less common.

SPIFFS is a much more reasonable alternatively (or even just expanding the main app partitions further), before doing so I'd like to explore what the impact is to the stock firmware if the SPIFFS partition is missing their expected data.

The TLDR is that this PR won't get merged in as it stands.

what about zstd (z-standard) compression? from a quick search, it seems to outpreform deflate in decompression speed.

I believe the zstd dictionary is significantly larger (resulting in needing 128MB of RAM to even just set it up). There might be some dictionaryless one-shot decompression like we're doing with deflate, but I haven't looked into it.

Also, given the small volume of bytes we're decompressing at a time (but doing it many many times), the throughput speed of the compression algorithm isn't the bottle here (afaict) but instead all the setup/teardown, which would likely be similar for zstd.

How about Tamp?

Planning to reapproach this with something like Group5 using bb_paper, will have a chat to bitbank2 about it.