GNOME Bugzilla – Bug 638613
Switch to activities overview very slow with r700
Last modified: 2012-11-20 07:42:09 UTC
When I have many windows open, switching to the overview is very slow on my system, e.g., with 20 mostly maximized windows distributed across 10 workspaces and 2 windows marked as "Always on Visible Workspace", it takes between 3 and 4 seconds to switch to the overview. The screen is frozen during that time, no intermediate frames are visible. Modifying WindowOverlay.show in js/ui/workspace.js to only be { this.title.show(); } (suggested by Owen) improves things so that the overview opens in less than a second, however, it's still not perfect (e.g., no intermediate frames). Without any windows open, it's fast. System information: Linux 2.6.36.2 on Intel Core i7 x86_64 system ATI Radeon HD 4770 (RV740 0x1002:0x94B3) using KMS and xf86-video-ati 6.13.2 Two monitors attached via DVI, both using 1920x1200 libdrm 2.4.23 Mesa 7.10 git as of 2011-01-03 (I earlier tested with Mesa 7.9 and that was 10 times as slow) X.org server 1.9.3 mutter 2.91.4 gnome-shell 2.91.4 Backtrace:
+ Trace 225390
== Stack trace for context 0xd5f0f0 == 0 [native frame] 1 anonymous() ["/usr/share/gnome-shell/js/ui/workspace.js":364] 2 anonymous(fade = false, overlay = [object Object], clone = [object Object]) ["/usr/share/gnome-shell/js/ui/workspace.js":1050] 3 anonymous(flags = 3) ["/usr/share/gnome-shell/js/ui/workspace.js":1004] 4 anonymous() ["/usr/share/gnome-shell/js/ui/workspace.js":1211] 5 anonymous([object Object]) ["/usr/share/gnome-shell/js/ui/workspacesView.js":80] 6 anonymous([object Object]) ["/usr/share/gjs-1.0/lang.js":110] 7 _emit(name = "showing") ["/usr/share/gjs-1.0/signals.js":124] 8 anonymous() ["/usr/share/gnome-shell/js/ui/overview.js":337] 9 anonymous([object instance proxy GIName:Meta.Display jsobj@0xfa6800 native@0xce76c0]) ["/usr/share/gnome-shell/js/ui/overview.js":389] 10 anonymous([object instance proxy GIName:Meta.Display jsobj@0xfa6800 native@0xce76c0]) ["/usr/share/gjs-1.0/lang.js":110] Kernel log excerpt: [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV740 0x1002:0x94B3). [drm] register mmio base: 0xFBDE0000 [drm] register mmio size: 65536 ATOM BIOS: Walden radeon 0000:01:00.0: VRAM: 512M 0x00000000 - 0x1FFFFFFF (512M used) radeon 0000:01:00.0: GTT: 512M 0x20000000 - 0x3FFFFFFF mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [drm] Detected VRAM RAM=512M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 4095696 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [TTM] Initializing pool allocator. [drm] radeon: 512M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. radeon 0000:01:00.0: irq 47 for MSI/MSI-X radeon 0000:01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode
Created attachment 177481 [details] [review] overview: Don't pick for every windowOverlay The number of picks increase with the number of windows that way, one pick after showing the overview is sufficent though so do that. --- Does not solve the actuall problems of picks being slow, but this seems like an optimization worth doing anyway.
Created attachment 177706 [details] [review] overview: Don't pick for every windowOverlay The number of picks increase with the number of windows that way, one pick after showing the overview is sufficent though so do that. -- *) Rebased
Request from one of the Radeon developers - while it's being slow, ssh in from another computer and run echo t > /proc/sysrq-trigger to get a kernel stacktrace in the kernel log - maybe repeat a few times. This may give some indication of what's going on when it's being slow.
Created attachment 179196 [details] kernel log I've attached the kernel log part for two instances of SysRq-T triggered via SSH. However, I don't see any stack traces, so I'm not sure whether this is really the output you've expected. Let me know if you need any further information. The system has been updated to Linux 2.6.37, Mesa 6.10, mutter 2.91.5, and gnome-shell 2.91.5 in the meantime. I'd say that performance improved a bit (between 2 and 3 seconds instead of between 3 and 4) but definitely still too slow for normal use.
Created attachment 183976 [details] [review] overview: Don't pick for every overlay Here's a new patch that uses global.sync_pointer() that 630842 adds == Don't do an individual hover fixup for every window overlay, instead just use the new global.sync_hover() to fix up hovers once we have finished showing the overview. Based on a patch from Adel Gadllah <adel.gadllah@gmail.com>
Review of attachment 183976 [details] [review]: Looks good and simple.
Comment on attachment 183976 [details] [review] overview: Don't pick for every overlay Patch pushed. Not going to close this bug, since there seems to be some underlying driver bug, though it's a little hard to figure out how we'd make progress in debugging whatever was going on. Attachment 183976 [details] pushed as c81c564 - overview: Don't pick for every overlay
Jürg, do you still have the hardware? Did things improve since then?
I used it until a couple of months back and it was much better than back when I filed the report. I consider this issue solved since this spring (GNOME 3.4 / Mesa 8 / Linux 3.3) or maybe even earlier.