GNOME Bugzilla – Bug 760462
[regression] Requesting treeview style context from CellLayoutDataFunc is causing endless pixel cache updates resulting in high CPU
Last modified: 2016-01-17 20:33:56 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
See https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/ ("What do you have to do ?" header)
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.
(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.
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.
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
(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.
I've documented the restrictions on the state argument a little better now.