Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache downloaded images #234

Open
CosmicHorrorDev opened this issue Feb 11, 2024 · 2 comments · May be fixed by #291
Open

Cache downloaded images #234

CosmicHorrorDev opened this issue Feb 11, 2024 · 2 comments · May be fixed by #291
Assignees
Labels
A-image Area: Image decoding/rendering/etc. C-enhancement Category: New feature or request

Comments

@CosmicHorrorDev
Copy link
Collaborator

We should respect some of the basic properties for image caching (with an easy way to clear the cache), so that we can avoid repeating a bunch of image calls if we have a valid cached image already. This should also speed up what seems to be the slowest visual part of document load times when we have a warm cache

@CosmicHorrorDev CosmicHorrorDev added C-enhancement Category: New feature or request A-image Area: Image decoding/rendering/etc. labels Feb 11, 2024
@CosmicHorrorDev
Copy link
Collaborator Author

Hashing out some of the details here

The cache

Currently I'm thinking of using something like redb for the cache itself. It's a pretty minimal pure-rust embedded database which should work well for our needs

Entries

The key itself would be the local path or url for the image. There's a bit of care involved to avoid bad keys where the local path should be resolved to an absolute path, and URLs that are hosted locally should likely be ignored from the cache

The actual image data itself will likely still just be the LZ4 compressed raw image data like how things are currently stored in memory. We should also version this format so that we can change the format in the future without to hack around things (keying by the path+version would allow for multiple versions to co-exist simultaneously which could be good)

Validity

For local files this should be as simple as storing and comparing the file's modified time to know if the cached entry is still valid

For local URLs we'll likely just always avoid caching outside of a single session

For remote URLs there's a lot more to consider in terms of storing and comparing the ETag and relevant Cache-Control information

Garbage Collection

We don't want the cache to grow forever, so we'll need to add some form of garbage collection. At the very least there should be a size limit on the cache (maybe default to something like 64MiB or 128MiB?) with maybe an LRU eviction policy?

It would also be nice to have a TTL (time-to-live) for each entry as well which should keep the cache small for people who only infrequently use inlyne. Having a TTL would also play well with cache-control for remote images since we can evict based on that as well

This can just be a once per session background task that kicks off after everything else finishes

CLI

There's enough functionality that having an inlyne cache subcommand would likely make sense. We could have functionality for cleaning the cache, showing stats, etc.

@CosmicHorrorDev CosmicHorrorDev self-assigned this Mar 27, 2024
@CosmicHorrorDev
Copy link
Collaborator Author

There's a lot involved here. I'll go ahead and start chipping away at things

@CosmicHorrorDev CosmicHorrorDev linked a pull request Mar 30, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-image Area: Image decoding/rendering/etc. C-enhancement Category: New feature or request
Projects
None yet
1 participant