When we first implemented the file scanner and got it testing in the UI, we ran into issues with the UI freezing and stuttering due to loading so many images with broken virtualization.
After fixing virtualization, the performance was good, but not good enough. We decided to use ImageSharp to resize each image to a standard set of sizes and save them to disk, passing the saved file path as the image Uri.
The problem
While this works, it has issues
Image processing only available to file-based cores
During simple metadata scans, preprocessing every single image is very CPU intensive.
Having the metadata scanner do image processing has always felt odd and out of place
The solution
After #185 is completed, we should move all image processing from AudioMetadataScanner into a plugin, but without all the concurrency handling (1 image resize per OpenStreamAsync call).
Additional requirements:
[ ] Make sure the multi-size options are made available on the plugin
[ ] Ensure the AbstractStorage is no longer used. There's no need to save the images to disk anymore.
[ ] Since the image processing carries dependencies with it, create a new project for this plugin.
[ ] Ensure all unit tests are moved out of StrixMusic.Sdk.Tests and into a new, dedicated test project.
[ ] Use the plugin in the existing app to show that it works.
Background
When we first implemented the file scanner and got it testing in the UI, we ran into issues with the UI freezing and stuttering due to loading so many images with broken virtualization.
After fixing virtualization, the performance was good, but not good enough. We decided to use ImageSharp to resize each image to a standard set of sizes and save them to disk, passing the saved file path as the image Uri.
The problem
While this works, it has issues
The solution
After #185 is completed, we should move all image processing from AudioMetadataScanner into a plugin, but without all the concurrency handling (1 image resize per
OpenStreamAsynccall).Additional requirements: