Description of problem: I cannot use gnome-shell because it is unusably slow - as in unable to keep up with typing in a terminal emulator window. "top" shows "mutter" running flat-out whenever I try to do something. Version-Release number of selected component (if applicable): gnome-shell-2.91.6-6.fc15.x86_64 clutter-1.6.4-1.fc16.x86_64 How reproducible: 100% Steps to Reproduce: 1. Log in normally with legacy config, note snappy behavior 2. gnome-shell --replace & 3. Brush cobwebs from mouse whenever something actually happens Actual results: Painfully slow behavior Expected results: A rapturous experience of the wonders of GNOME 3 and gnome-shell Additional info: Running gnome-shell also, for some reason, wipes out the workspace manager's preferences. kernel 2.6.38-0.rc5.git1.1.fc15.x86_64 Graphics chipset according to X: [ 12.376] (II) intel(0): Integrated Graphics Chipset: Intel(R) Q35 [ 12.376] (--) intel(0): Chipset: "Q35" lspci sees it as: VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Hmm, that's a bit odd, I have a Q35 on a desktop system at home, and it works fine with the shell at 1920x1200, though I haven't necessarily tested with the very last rawhide kernel. A Q35 is basically just a 945 core hooked up to slightly newer and better memory subsystem so it's nothing very exotic. Can you attach the output of 'glxinfo' - the most likely guess is that you might be falling back to software rendering for some reason. (If it's falling back, there's a way of setting MESA_DEBUG/MESA_VERBOSE environment variables to get it to tell you why ... though I don't remember the details right at this moment.) In terms of workspace handling - it's intentional - the workspace handling we're trying for in GNOME Shell is much more about creating workspaces on demand rather than having workspace 3 reserved for emacs and workspace 4 reserved for mail. (This obviously will cause some pain for people with established habits, but we think it's worth it to make workspaces accessible and convenient to a larger set of users.) This will make more sense with the next version of the shell which should be hitting rawhide tomorrow or Wednesday - it adds workspace thumbnails in the overview and automated workspace management. (empty workspaces are pruned and a new empty workspace is added at the end if something is added to the existing last workspace.)
Created attachment 479939 [details] glxinfo output OK, here's the glxinfo output.
(In reply to comment #2) > Created attachment 479939 [details] > glxinfo output > > OK, here's the glxinfo output. Hmm: OpenGL renderer string: Mesa DRI Intel(R) Q35 GEM 20100330 DEVELOPMENT So, not software fallback. * What screen resolution? * Can you provide the output of: gnome-shell --perf=core --perf-iters=3 --replace with only one terminal window open? * How many windows do you typically have open?
> * What screen resolution? According to xdpyinfo: dimensions: 3840x1200 pixels (1016x318 millimeters) I'm running two monitors, each with 1920 resolution. > * Can you provide the output of: > gnome-shell --perf=core --perf-iters=3 --replace stdout was: ------------------------------------------------------------ # Additional malloc'ed bytes the second time the overview is shown leakedAfterOverview -17088, -17824, -18496 # Frame rate when going to the overview, first time overviewFpsFirst 0.185985179771, 0.1868570017, 0.186856984242 # Frames rate when going to the overview, second time overviewFpsSubsequent 0.219831723213, 0.221460153228, 0.221460104184 # Time to first frame after triggering overview, first time overviewLatencyFirst 12532, 10439, 12706 # Time to first frame after triggering overview, second time overviewLatencySubsequent 5685506, 5557206, 5557210 # Malloc'ed bytes after the overview is shown once usedAfterOverview 17476656, 17452720, 17414816 ------------------------------------------------------------ I also got this on stderr: (mutter:21500): Cogl-glx-WARNING **: Skipping layers 1..n of your pipeline since the first layer is sliced. We don't currently support any multi-texturing with sliced textures but assume layer 0 is the most important to keep JS LOG: Failed to acquire org.freedesktop.Notifications; trying again JS LOG: Cannot create "Network" item, .desktop file not found or corrupt. JS LOG: GNOME Shell started at Mon Feb 21 2011 09:47:27 GMT-0700 (MST) Window manager warning: Log level 16: NOTE: Not using GLX TFP! > * How many windows do you typically have open? I normally work with six workspaces and often manage to populate them all. I've never even attempted that with gnome-shell, though; just having a terminal and maybe firefox open is enough to dissuade me from trying any more...
Here's a clue...typing the above inspired me to try turning off the second monitor. That fixed the performance problem - things move quickly now. Only problem is...I miss all those pixels...
overviewFpsSubsequent 0.219831723213 - 5 seconds per frame - yeah, not usable. the thing you are hitting here is that all 945 derived cores, including the Q35 have a hard limit of 2048 pixels wide for 3D rendering. So while glxinfo is reporting that your card/drivers can do 3D acceleration, as Mesa is actually asked to do it across both monitors, it falls back to software. There are plans that have been floating around the Linux graphics community for a while for how to work around that, but I don't expect anything to come of it soon. For now about all we can do is not try to run GNOME Shell if we detect such a configuration. Of course, for a desktop system, a fix is to install a discrete graphics card. Radeons from the last 5 years work well (avoid HD 6000 series, too new, and for dual 1920x1280 you'll benefit from a card with a 128-bit memory bus instead of 64-bit)
Interesting...so if I put the second display below the first, it might work? I'll give that a try when I get a chance. That would be a bit weird to interact with, but one can get used to all kinds of things... I can see how that limitation could be hard to work around, anyway. It might be nice, at least, to put up a little dialog saying "your configuration is not supported; by the time you get any work done, we'll have solved global warming and fixed the budget deficit." Or something like that. Thanks for looking into this!
Just for anybody who is curious: putting the second display below the first also leads to slow-as-molasses mode; perhaps the 2K limitation applies in both directions.
*** Bug 692094 has been marked as a duplicate of this bug. ***
Owen, would it be possible to go into more detail about which integrated graphics cards would face this limit please? I'm about to purchase a used laptop and I'd like it to be compatible with gnome-shell and my 1920x1080 external monitor. Do know if the X4500 or Arrandale Core i7 series integrated GPUs would have this problem you're describing? Thanks, Matt
I've just installed Fedora 17 Beta on my quite powerfull laptop, yet gnome-shell, no surprise there, is still slow and animations are sluggish and buggy. My laptop is equipped with i7 ULV processor with intel graphics build in - where Gnome 2 and compiz worked super fast, Gnome 3 and it's shell are unacceptably slow and sluggish. Running kernel 3.3.2-8.fc17.x86_64 on CPU0: Intel(R) Core(TM) i7 CPU U 680 @ 1.47GHz stepping 05 equipped with: Intel HD Graphics Chipset I am expecting gnome-shell to run smoother and faster than gnome2+compiz, as it should have better code and less fancy features. Unfortunately it's not. Old good Gnome2+compiz works far better.
markm, This bug was resolved and it turned out to be a hardware limitation (which, as far as I can tell, does not apply to your hardware). If you are experiencing poor graphics performance, please go to the IRC support channel for troubleshooting help or file a new bug. Matt
(In reply to comment #10) > Owen, would it be possible to go into more detail about which integrated > graphics cards would face this limit please? > > I'm about to purchase a used laptop and I'd like it to be compatible with > gnome-shell and my 1920x1080 external monitor. > > Do know if the X4500 or Arrandale Core i7 series integrated GPUs would have > this problem you're describing? The X4500 and the Ironlake graphics in Arrandale have considerably larger limits - I don't remember what they are offhand.... probably at least 4096x4096. (I know my Ironlake laptop is capable of driving 1400x1050 next to 1920x1080.) http://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units has information about different GPUs, though not texture size and rendering area limits.
(In reply to comment #12) > markm, > > This bug was resolved and it turned out to be a hardware limitation (which, > as far as I can tell, does not apply to your hardware). > > If you are experiencing poor graphics performance, please go to the IRC > support channel for troubleshooting help or file a new bug. > > Matt Thanks for the info. I've solved my issue by installing MATE Desktop and compiz -- it works flawlessly, much better than gnome-shell.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.