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 760462 - [regression] Requesting treeview style context from CellLayoutDataFunc is causing endless pixel cache updates resulting in high CPU
[regression] Requesting treeview style context from CellLayoutDataFunc is cau...
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2016-01-11 14:01 UTC by Stephen Brandt
Modified: 2016-01-17 20:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case. Compile with command: valac --pkg gtk+-3.0 testcase.vala (1.99 KB, text/x-vala)
2016-01-11 14:01 UTC, Stephen Brandt
Details

Description Stephen Brandt 2016-01-11 14:01:41 UTC
Created attachment 318730 [details]
Test case. Compile with command: valac --pkg gtk+-3.0 testcase.vala

Few days ago I got a bug report from a Haguichi [1] user, that it was using lots of CPU when the window was visible and the network list filled [2]. As I could only reproduce this on distro's running Gtk+ 3.18, it was safe to assume my app hit an Gtk+ regression. With this reproducable case and the gitlog for Gtk+ 3.18 mentioning "pixel cache" a lot of times [3] the cause was found quite soon. GTK inspector showed treeview disco with "Show Pixel Cache" turned on.

The question still remained what triggered these endless pixel cache updates. Thankfully, i discovered it was requesting the style context of the treeview from within the CellLayoutDataFunc. As soon as i moved that request outside of that function CPU pixel cache updates were normal again and so was CPU.

So it seems likes this triggers a loop. Requesting style context triggers pixel cache refresh, which triggers the CellLayoutDataFunc, which requests the style context that triggers the pixel cache again, etc, etc.

I have attached a simple testcase to reproduce this bug.


[1] https://www.haguichi.net
[2] https://bugs.launchpad.net/haguichi/+bug/1531587
[3] https://git.gnome.org/browse/gtk+/log/?h=gtk-3-18&qt=grep&q=treeview
Comment 1 Christoph Reiter (lazka) 2016-01-11 14:25:50 UTC
See https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/ ("What do you have to do ?" header)
Comment 2 Stephen Brandt 2016-01-11 15:04:27 UTC
Christoph: That blog post only mentions 3.19.x. The regression I describe occurs already in 3.18. Even so, a blog post is a very bad excuse for regressions or deliberate breakage.
Comment 3 Christoph Reiter (lazka) 2016-01-11 15:39:17 UTC
(In reply to Stephen Brandt from comment #2)
> Christoph: That blog post only mentions 3.19.x. The regression I describe
> occurs already in 3.18. Even so, a blog post is a very bad excuse for
> regressions or deliberate breakage.

True and true. I just remember something similar in 3.18 that was also fixed by this change. I don't know more than you do about this, but maybe the code in the blog post helps in your case.

GTK+ devs probably know more about this.
Comment 4 Timm Bäder 2016-01-11 19:56:50 UTC
The fact that using the wrong state flags prints a warning is new, nothing else. I can reproduce the high memory usage in that code snippet and I can fix it by using the mentioned save/restore calls.

I.e. 3.19 now tells you that you're doing something wrong.
Comment 5 Stephen Brandt 2016-01-13 13:58:40 UTC
So then why has the get_color call [1] a state parameter, as that parameter suddenly only accepts the state it's currently in...?

[1] http://valadoc.org/#!api=gtk+-3.0/Gtk.StyleContext.get_color
Comment 6 Matthias Clasen 2016-01-16 19:27:15 UTC
(In reply to Stephen Brandt from comment #5)
> So then why has the get_color call [1] a state parameter, as that parameter
> suddenly only accepts the state it's currently in...?
> 
> [1] http://valadoc.org/#!api=gtk+-3.0/Gtk.StyleContext.get_color

The parameter is there for historical reasons. We won't just change the api. As our css implementation has matured, it has become clear that we can't quite keep the promise that the style context APIs make. 

We should look at introducing new api without the state parameter.
Comment 7 Matthias Clasen 2016-01-17 20:33:56 UTC
I've documented the restrictions on the state argument a little better now.