Run more than one thumbnailer processes at a time
Use cases
When viewing folders with many images or videos, thumbnail generation seems to progress in a synchronous fashion. While some improvement can be made by using a different thumbnailer such as ffmpegthumbnailer, the underlying speed problem may be due to a synchronous for loop rather than generating all icons within the view at the same time.
You can see this synchronous behavior while viewing a folder with many videos. After the first thumbnail is generated it progresses to the next one, then the next, and so-on until it's done.
This feature is asking for thumbnail generation to happen asynchronously, with respect to computer resources.
Desired behavior
The CPU has a number of cores and a number of threads that could be utilized to a greater extent. It's possible to split the thumbnail generation into smaller chunks and process those chunks in separate threads, perhaps even getting to the individual file level if the CPU resources are available.
When the user opens a folder containing videos or images, nautilus should generate the thumbnails as quickly as possible with little regard to order. The only consideration could be to prevent generating thumbnails outside of the viewable area, such as below the scroll area. This would allow the system to process fewer files and complete the thumbnail generation sooner.
As it does now, if the user scrolls to a new area then those thumbnails would be generated in an asynchronous fashion.
Benefits of the solution
- Users see thumbnails sooner
- Total thumbnail generation time is significantly reduced
- Thumbnails only need to be generated for the viewable area, so fewer thumbnails overall need to be created
- Possible reduction in system resources due to reduced time to generate thumbnails
- Better utilization of system resources
- Behavior is similar to websites that load many images in a grid using asynchronous requests for image files. Users are accustomed to this.
Possible drawbacks
The order of thumbnail generation currently is based on the first thumbnail in the window, then the next, and the next.
In asynchronous processing all thumbnails are equally weighted, so the user might see a thumbnail created in the middle of the screen or at the end of the list before the first thumbnail is created. It's possible that the first file could be the last thumbnail to be generated. If thumbnail generation is sped up by this feature then this may not be an issue.
Some systems with limited resources may see a negative user experience if thumbnails are generated out of order and they take a significant amount of time to process.