GNOME Bugzilla – Bug 751082
GtkTreeView draw performance is bad when contents are not larger than allocation
Last modified: 2015-08-20 18:15:56 UTC
Another performance "issue" found from animated sequences in Builder when a GtkTreeView is in play. Despite not changing the allocation at all, GtkTreeView still goes through a lot of full redraws of the bin window. This is happening because often times the treeview is not larger than the widget allocation. This causes pixelcache to not pixelcache the contents (since it was primarily aimed at scrolling performance) and results in jittery drawing. Two patches provided: 1) allow a widget to always require that pixelcache cache drawing contents. 2) Teach GtkTreeView to always pixel cache when a model is attached. This makes a few animated sequences in Builder very smooth, finally!
Created attachment 305439 [details] [review] allow widgets to require pixelcaching This lets a widget using GtkPixelCache to require the pixelcache always cache window contents.
Created attachment 305440 [details] [review] pixelcache treeview contents when a model is set This makes GtkTreeView always cache the contents using pixelcache.
I also notice that after initially attaching a model, I see a lot fewer full exposes now (presumably caused by row sizing/etc).
Review of attachment 305439 [details] [review]: sure
Review of attachment 305440 [details] [review]: This will use some more memory for things that display treeviews that rarely change but are often visible, say like a sidebar. However, we blow unused caches after 20 seconds, so this will only affect the active app, so it is probably ok.
Yeah, I was thinking the same thing. Just a bit more memory but only temporarily and it can potentially save a bunch of operations that could be more expensive than the bit extra memory.
I have a python application here that apparently is slightly broken and calls set_model after the GtkTreeView has been destroyed. I think in this case it is an idle handler that is still holding on to the widget after it has been destroyed. This application crashes because of this patch. A simple check whether pixel_cache is not NULL should fix the crash. Not quite sure about the guarantees that GTK+ does here, but it seems wrong to crash in this case.
Thanks for reporting. I went ahead and put the NULL check in place as suggested. Should preserve the previous state of things. Fixed in commit b37400752bdc282888e13c9d74aa3e904bab8283.