-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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
[vfs][imagecache] Separate 'image://' VFS protocol from TextureCache #25063
Conversation
6dc6110
to
f895c2f
Compare
jenkins build this |
jenkins build this please |
1 similar comment
jenkins build this please |
That is code I removed, I'm not formatting it. |
Any thoughts on this? It's mainly refactoring and not very interesting, I'll merge it soon if there are no objections. I just started dogfooding a class named |
simplify a bit. It was only used by embedded loaders, and we may be better served always getting 'full size' from loaders and then resize during cache
all images can be cached on demand now
I've made some formatting changes to meet the current code style. The diffs are available in the following links: For more information please see our current code style guidelines. |
Description
Create a strongly-typed ImageFileURL to manage image files, particularly for special images and their options.
Mostly the same functionality but some small changes:
size=thumb
image option that mostly just doubled the cache size in the picture browserchapter://nfs://...mkv/2
image path toimage://video@nfs%3A%2F%2F...mkv/?chapter=2
to match all other generated image paths. The old images will stay in the texture cache for now.Commits are separated into steps of the refactoring.
Motivation and context
Separate, organize, and clarify some functionality around images, special images, and image caching.
Enable future work: in the future, path options could be used to change current embedded video image loader that uses a "dynamic" special type like
video_poster
andvideo_fanart
to a static type likevideo_embed
with optionembed_type=fanart
- that gives us an easy place to support more embedded images and special type is more suitable to be an enum.I'm also curious if the generated video image loader is accurate enough for repeatable bookmarks:
video
special type with an option liketime_in_seconds=600.66
.How has this been tested?
Dogfooding for a couple weeks, and I moved the few tests from the previous implementation.
What is the effect on users?
Potential mild speedup in the picture browser when images aren't cached yet, and video chapter images will regenerate once after this when viewed in the chapter browser.
Screenshots (if appropriate):
Types of change
Checklist: