Thumbnail generation and large folder loading could be faster in general

[abodedis]

Problem

Thumbnail generation and large folder loading could be faster in general.

Proposal

As of this writing, Elementary OS generates image thumbnails faster than the default file managers in other distros, but the wish is to load large folders instantaneously, or at the least, fast enough that the user does not notice the wait. This will be useful for artists and those who manage thousands of images in a folder and would rather not wait several seconds or minutes for a large folder to load, and do not want to install another file manager because Files is great!

The image thumbnailer and/or whatever loads the files could utilize multiple threads and/or the GPU. Currently, it appears that Files does most, if not all, of its processing on only one CPU thread. Most users these days have multi-core, multi-threaded processors and powerful GPUs.

If whatever code that currently loads the files is based on ancient code/libraries, then that code could be rewritten to take advantage of modern hardware.

Prior Art

[jeremypw]

The rate limiting step is not the thumbnailing - that is already optimised by only requesting thumbnails when the item is actually visible. The main problem is Gtk.IconView being very slow and inefficient in laying out and displaying large folders. I understand the performance in Gtk4 is generally improved so hopefully that will ameliorate the issue when we can move to it. At the moment working with large folders is better done ListView which is much faster in laying out and drawing.

I did some work on a custom widget here - https://github.com/jeremypw/widget-grid - which is almost unaffected by folder size but there is no real appetite in elementary to develop and support a complicated custom widget.

[jeremypw]

I did test on a large folder of files recently and found Files loaded it much more slowly (from a spinning disc) than I remember it used to, even using ListView. Need to investigate what has caused this regression.

[jeremypw]

I think the slow down may be related to recent porting of the custom model used to Vala and basing it on Gtk.TreeStore - it seems that the time take to add files to the model increases quadratically with number of files even with sorting disabled - not sure why yet. The maximum reasonable usable folder size with a spinning disc is about 1000 - 2000 items now.

If model performance is the culprit, multi-processes will not improve things. We need a model that can be updated with multiple files efficiently.