After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692348 - Dogslow / laggy experience when switching between active/inactive windows with Adwaita and GTK IconView
Dogslow / laggy experience when switching between active/inactive windows wit...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkIconView
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 141154 682886
 
 
Reported: 2013-01-23 02:04 UTC by Jean-François Fortin Tam
Modified: 2018-04-14 23:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screencast (791.36 KB, video/webm)
2013-01-23 02:04 UTC, Jean-François Fortin Tam
Details

Description Jean-François Fortin Tam 2013-01-23 02:04:05 UTC
Created attachment 234160 [details]
screencast

As the attached screencast demonstrates, performance rapidly becomes a problem with iconview and Adwaita. I set the option to use the dark variant of GTK themes on all my applications, but other than that it's a stock system.

In my case, the pitivi iconview contains roughly 650 items. The columns arrangement is left for GTK to consider automatically, and the labels are ellipsized by Pango.

I noticed at first that it was sluggish to open subwindows or to focus other widgets (the whole application UI would lack responsiveness)... But what you see in the attached screencast tells me it might have something to do with the "insensitive" look of unfocused windows.


This is on a Core2 Quad Q9300 CPU and Gallium 0.4 radeon driver for AMD Radeon HD 5450.
Comment 1 Jean-François Fortin Tam 2013-01-23 02:05:39 UTC
Also: not sure if it's actually a bug in GTK+ or the Adwaita engine.
Comment 2 Jean-François Fortin Tam 2013-01-23 02:19:05 UTC
Ah, and this is proportional to the amount of items in the iconview. If you only have a handful, there is no noticeable performance slowdown.

The listview, with the same amount of items, is not affected, so it might be iconview being overzealous and recalculating the position/wrapping/ellipsizing of everything when it shouldn't, or something like that (just throwing a guess).
Comment 3 Matthias Clasen 2013-01-23 12:50:08 UTC
The icon view doesn't have any of the async validation machinery of the treeview, thus it is expected to become slow much earlier. But it would certainly be worthwhile to look for any O(n^2) gotchas.
Comment 4 Jean-François Fortin Tam 2013-02-20 18:22:29 UTC
For the record, I should add a quick mention unrelated to the speed of switching focus with such an iconview: in Pitivi, we had to actually implement a queue to fill the iconview only by batches of 50 (instead of letting it add items one at a time) because of the general slowness.
Comment 5 Carl 2014-08-10 11:24:29 UTC
I can confirm issues with the IconView for large numbers of items (5000).

Adding logging to my model taught me that IconView requests all the data of the model (calling get_value for the 5000 items) the first time it is displayed.
Even if only 25 items have to be  displayed.
Even if the column is fixed sized.

This behavior kills the performance of my application.

I replaced the iconview with a treeview ( with fixed height) and the first display was instantaneous, proving me that the issue was not in my model.

And indeed the added logging confirmed that treeview only requests the data that have to be displayed.

Could IconView implement the same mechanism?
Comment 6 Matthias Clasen 2018-02-10 05:11:46 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 7 Matthias Clasen 2018-04-14 23:56:00 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new