GNOME Bugzilla – Bug 633178
combo box very slow on gtk3
Last modified: 2018-03-23 18:34:08 UTC
Steps to repro: 0) Build gucharmap --with-gtk=3.0 1) Install every font package your distro has 2) Start gucharmap, and click on the font combo box to pop it up 3) Select and item, to pop the combo box down Actual results: Step 2) takes a very long time; and after step 3) it takes a long time until the programme is responsive again. Expected results: Steps 2) and 3) are pretty much instantaneous, even though the font list is very large. This works as expected on a gtk2 gucharmap build (--with-gtk=2.0), so this is clearly a gtk3 regression.
Slowness in 3) even happens when popping down the combo box without selecting anything (e.g. by pressing Escape key). In this case, no new font is selected, so any slowness of redrawing isn't due to gucharmap switching to a new font.
Seems to be fallout from the popup width changes, at least, it is stuck in size allocation.
The slowness of popping up the combo is still reproducible using gtk+ master from today. (Popping is down again, while still a bit slow, isn't nearly as bad now.)
Confirmed in GTK+ 3.0.6 and epiphnay browser (simply try to change the product field below)
*** Bug 650858 has been marked as a duplicate of this bug. ***
Same problem with Empathy's protocol chooser (see bug #650858). Note that we don't observe this regression when removing the pixbuf renderer displaying the protocol icon.
Whew, looks like I was not imagining things. Was wondering if it was by design (ie: lazy loading the combobox items). If this is the result of lazily loading the contents, I was thinking maybe it would be possible to pre-load it when the mouse cursor is over the combobox widget (or not paint the thing until it is actually loaded)
We solved this in Empathy by rendering the pixbuf directly; see http://git.gnome.org/browse/empathy/commit/?id=b0bd73cfa5658971f12c86a1f3711cab663a3f40
But that's not very practical (more work for the same result), and I suspect you'd need to listen to theme changes if you want to be completely correct...
Still reproducible with gucharmap on gtk 3.2.0. Gucharmap just uses a text combo, it has no pixbuf/icons/etc in the combo.
Bump. Is combobox still slow in 3.10?
It's not as bad as it used to be, but the font combo in gucharmap still takes 2-3 seconds to pop up.
(In reply to comment #12) > It's not as bad as it used to be, but the font combo in gucharmap still takes > 2-3 seconds to pop up. the combo box in gucharmap on a stock fedora 20 installation is nearly instantaneous.
Created attachment 256246 [details] screencast of the gucharmap combo box with gtk 3.10
it would be good to have a profiling trace to see what's the ComboBox doing on pop down.
How many fonts do you have installed? $ fc-list | wc -l 654
definitely not as many :-) around 150 fonts installed (again: it's pretty much a stock f20 installation) if it's happening on pop down then it may mean that we're doing too much work on hide/destroy, like invalidating styles/renderers for stuff that won't be displayed.
How is this in 3.22?
Still not instantaneous, just slow enought for the delay from click to pop up to be noticeable (about half a second), but bearable.
Thanks for the update! I guess we might as well close this, then; changes that would affect it in GTK+ 3 are very unlikely at this point, whereas GTK+ 4 is an entirely different kettle of fish as discussed at https://gitlab.gnome.org/GNOME/gtk/issues/55 and https://gitlab.gnome.org/GNOME/gtk/issues/80