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 568574 - title bar updates slow/laggy when lots of windows open
title bar updates slow/laggy when lots of windows open
Status: RESOLVED FIXED
Product: Sawfish
Classification: Deprecated
Component: Window Manager
1.3.x
Other All
: Normal minor
: 1.5.x
Assigned To: Christopher Roy Bratusek
sawfish-maint
Depends on:
Blocks:
 
 
Reported: 2009-01-21 16:47 UTC by Trevor Cordes
Modified: 2009-07-03 16:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
first attempt at fixing the issue (446 bytes, patch)
2009-06-08 16:27 UTC, Christopher Roy Bratusek
none Details | Review
fix in the fix (460 bytes, patch)
2009-06-08 16:39 UTC, Christopher Roy Bratusek
none Details | Review

Description Trevor Cordes 2009-01-21 16:47:27 UTC
Please describe the problem:
At any given time I have 16 workspaces and 150-200 windows open.  Anything that updates the window frame title bar (like changing directory in my xterms, or browsing to a new page in firefox, or hitting next-image in xv) takes about .5 to 1 sec on my unloaded Core2 Quad 2.4GHz workstation.  During the .5-1 sec interval, if you click on another window for focus, your click will do nothing and not register until the .5-1 sec interval has passed, and then the other window will focus.  It's like you can't do anything at all while the wm is thinking.

Moving, resizing, etc is normal speed.  It is only updates to the title that is slow.

If I have few windows open, like when I reboot and start fresh or close most windows before shutdown, then everything is very fast as you would expect.

My hunch is that some of the code that matches title bars is running slow lisp code against every title bar change and every window open in a sequential check.  I do use matched windows to hide some windows from the taskbar.

The solution will be to optimize the check when titles change, as you would only need to check the current window, possibly; or make the code faster with a better algorithm.

Thanks!


Steps to reproduce:
1. open 150-200 windows
2. in firefox, browse to a new page
3. immediately click on another window



Actual results:
The other window click will not register for .5-1 sec.

Expected results:
It should focus immediately.

Does this happen every time?
yes

Other information:
It has done this since at least 1.3.4.  I am currently using 1.3.5.1.
Comment 1 Trevor Cordes 2009-01-21 17:09:51 UTC
I found a workaround while running tests/benchmarks on this bug.  The bug ONLY occurs with the theme microGUI!  All other themes I tried, which is most of them, did not have this bug.  Perhaps it is something about the microGUI theme and how it makes the title bar pretty.  So my theory about matched windows is incorrect.

Workaround: use another theme.
Comment 2 Janek Kozicki 2009-01-21 19:13:56 UTC
Thanks for report, I updated wiki page: http://sawfish.wikia.com/wiki/MicroGUIx2
Comment 3 Christopher Roy Bratusek 2009-01-21 21:45:45 UTC
I'll see, what I can do.
Comment 4 Christopher Roy Bratusek 2009-06-08 16:27:50 UTC
Created attachment 136152 [details] [review]
first attempt at fixing the issue

Could you try it with that patch? this is the only real different between microgui and the other themes.
Comment 5 Christopher Roy Bratusek 2009-06-08 16:39:12 UTC
Created attachment 136153 [details] [review]
fix in the fix 

fixed a small thing in the fix
Comment 6 Christopher Roy Bratusek 2009-06-08 17:00:37 UTC
did more testing on that theme (...) the top-left-blue part my the issue (...) 

try animated-viewport-scrolling at 50 steps and an maximized, microgui framed windows -> you'll see that the top-left-blue part takes the longest to be calculated.
Comment 7 Christopher Roy Bratusek 2009-07-03 16:19:14 UTC
commited, fixed.