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 684499 - Transitioning to backdrop makes the columns resize
Transitioning to backdrop makes the columns resize
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Class: GtkStyleContext
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-09-20 18:55 UTC by William Jon McCann
Modified: 2018-02-10 04:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description William Jon McCann 2012-09-20 18:55:59 UTC
1. Open /etc
2. Switch to list view
3. Have Name, size, type, modified visible (in that order)
4. Click on the titlebar

The size column jumps around.
Comment 1 Cosimo Cecchi 2012-10-03 00:38:04 UTC
-> gnome-themes-standard

It turns out that the bug lies in between GTK+ and the theme.
The problem is that we're using non-standard style properties for focus in the Adwaita engine, and by doing so we hit a slow path in the re-styling code; I now changed the engine to read values from standard CSS style properties, and the bug seems to be gone.
Comment 2 Cosimo Cecchi 2012-10-03 16:41:43 UTC
-> gtk+

Unfortunately, while this fixes the reported bug, a similar glitch still seems to happen when the window goes to the backdrop state.
It doesn't look like we're doing anything wrong in the theme though, so reopening and reassigning to GTK.
Comment 3 Cosimo Cecchi 2012-10-03 17:02:11 UTC
Might be related to bug 662527
Comment 4 Benjamin Otte (Company) 2012-10-04 10:52:11 UTC
Is that an auto-sizing treeview? Because if so, that's a treeview bug. The treeview needs to figure out the sizes to use for the columns. And for that, it decides to measure all the rows.

As it turns out, measuring the (on my computer) 271 rows takes longer than 10ms, so it gets delayed and done in 10ms chunks.

And of course, whenever the code figures out that a row has longer text, it resizes the columns. So if you're lucky you get repaints every frame.

How often do we need to do this recalculation? Well, whenever styles change. And when do styles change? Well, whenever the CSS possibly changed anything. Like when we go to backdrop, focus, etc. Or when a sibling or parent widget does.
Comment 5 Matthias Clasen 2018-02-10 04:39:04 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.