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 637155 - Remove vestiges of support for themes using XSHAPE
Remove vestiges of support for themes using XSHAPE
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2010-12-13 16:13 UTC by Owen Taylor
Modified: 2010-12-15 03:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
pygtk test case (758 bytes, text/x-python)
2010-12-13 16:15 UTC, Owen Taylor 		Details

Description Owen Taylor 2010-12-13 16:13:14 UTC 
There's still some pieces of code in GTK+ that were written for an early idea that a theme engine could shape GDK windows behind the back of a widget.

In particular:

 gtk_widget_reset_shapes()

And:

 gtk_widget_set_style_internal()

It turns out that (because of a missed optimization in GDK) this is actually a big performance bottleneck with CSW, and it's entirely pointless. (Will filed a separate bug about the missed optimization.)

I'm pretty positive no theme engine has done this since some early prototypes that rasterman wrote, would suggest:

 - Remove the call from gtk_widget_set_style_internal() and deprecate the function in gtk2. (If we are still doing deprecations in gtk2)

 - Remove the function entirely in gtk3.
Comment 1 Owen Taylor 2010-12-13 16:15:42 UTC 
Created attachment 176340 [details]
pygtk test case

As you increase the SIZE constant, the attached program spends all it's time in gtk_widget_reset_shapes()

(You get a O(n^2) behavior because it walks over all the sibling windows of the entry for each entry)
Comment 2 Dave 2010-12-14 00:44:46 UTC 
I have tested and verified his fix.  My application suffered particularily badly before this fix due to a very large number of widgets in use. multiple 16x16 grids (5-8 depending on runtime configuraion) of GtkEntries having their backgrounds set via gtk_widget_modify_base during the update routine (which is only ran once, and never again in most cases) took well over 17-20 seconds to complete.  With the revised code, it takes less than 1 second to complete (17-20x improvement).    Using owen's testcase python app, I was only able to get a 11x11 grid before cpu usage would skyrocket, maxing out at 14x14 (196 entries). With the patch I was able to get to a 40x40 (1600 entries) grid updating at almost the proper rate with 50-80% cpu usage.