Open DropsOfSerenity opened 4 years ago
In Files. this is largely due to upstream issues with the Gtk.IconView, which is not very efficient for large numbers of items as it lays out all the items regardless of whether they are visible. You will probably find that the ListView is much faster for browsing folders with large numbers of items (uses Gtk.TreeView but otherwise the same Files code). It was decided not to support a custom widget for the IconView in order to simplify the code.
Nautilus does not use IconView for this reason, seems like IconView is not fit for purpose here.
If there were a suitable widget written in Gtk/Vala available off the shelf we would probably use it. I find Iconview is usable up to several thousand items (if you do not mind a slight lag) but otherwise there is always ListView, which pretty much every thing IconView does.
There is this: https://github.com/jeremypw/widget-grid but it is unlikely to be used in elementary.
Having a limitation like this in here makes it feel pretty bad for anyone who does things with files on their computer (lots of people.) I'd recommend removing icon view until a suitable replacement can be found.
Folders with many items also take a long time to just load in. Maybe items can be populated asynchronously?
@ChildishGiant Items are loaded asynchronously but until they are all loaded the view cannot know what order to show them in. They are not guaranteed to be loaded from disc in the same order the view is set to display them.
Surely they could be sorted when added, instead of sorted once they've all been loaded?
Then the items would keep jumping around as more and more are added and the view would keep getting redrawn - which would get slower and slower as more items are added.
If there were a suitable widget written in Gtk/Vala available off the shelf we would probably use it. I find Iconview is usable up to several thousand items (if you do not mind a slight lag) but otherwise there is always ListView, which pretty much every thing IconView does.
There is this: https://github.com/jeremypw/widget-grid but it is unlikely to be used in elementary.
What about a custom Gtk.FlowBox + GLib.ListModel that only create widgets to the visible area, trying to replicate the Gtk.GridView from Gtk4?
that can work as a stopgap until we can use Gtk4 and as a preparation step to it too, since the ListModel based views have better scalability than the TreeModel based ones.
Getting it perfected, reviewed and merged into Files would be a major undertaking with no guarantee of success. Gtk4 would probably come sooner. I also considered whether the grid used in Photos could be adapted but such a major effort would require support from the top.
If you were to provide a PR of such a widget I would be happy to review it. It would be an opportunity to also reconsider how the UX could be improved to make the mixed-mode click handling more natural e.g. making it visually clearer that folders and files are different things and behave differently.
I have recently found that there has been a regression in performance loading folders initially due to porting the underlying model to Vala - I am working on a fix that speeds this up greatly. There is still a significant delay in laying out the IconView though which can only be fixed upstream. It is better to use ListView for large folders for now.
Prerequisites
Describe the bug
In my music folder (which has 1000+ folders) every action is slow, resizing the window is slow, creating a new folder and typing the name is slow, etc.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No lag when resizing window, no lag when performing actions like typing in filenames.
Screenshots or screen recordings
Platform Information
Additional context
This seems to happen in terminal as well when there is lots of text in the buffer, not sure if it's related to scroll view performance or what, likely upstream widget issue, either way we should get to the bottom of it.