-
-
Notifications
You must be signed in to change notification settings - Fork 400
refactor: offload thumbnail rendering to multiple processes #953
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
base: main
Are you sure you want to change the base?
Conversation
Cool! Which module will handle loading the thumbnails? I want the thumbnail renderer with multiprocessing to be modular so i can generate a specific thumbnail when i wanted for different purposes. for example, i want to generate audio thumbnail as in the following video to use it in the music player widget. 20240930-1809-39.6288321.mp4 |
I'm a bit out of the loop on the purpose of this refactor, as the thumbnail renderer was already multi-threaded. I'm also not sure why the |
With multi-threading the render threads and main thread have to share the GIL. The multi-thread approach is able to use more cpu still since the libraries used for image manipulation can do work without needing to aqcuire the GIL. But any python code or library code interacting with python objects will freeze the main ui thread. Video showing the ui freeze when rendering thumbnails |
Summary
Renders can now be queued using the
ThumbnailManager
class which keeps a pool of processes to perform render jobs.CacheManager
has been rewritten. The caching folder layout has changed to{hash[:2]}/{hash}-{mtime}.webp
It does remove outdated cache items but doesn't support a max cache size.
TODO
Tasks Completed
Platforms Tested:
Tested For: