| |||||||||||||
extensions.gnome.org launchesextensions.gnome.org launchesPosted Dec 2, 2011 3:01 UTC (Fri) by MisterIO (guest, #36192)Parent article: extensions.gnome.org launches
At first my main problems with the gnome-shell were basically about usability. I found it (and still do) to be much worse than gnome2, but I could somehow even leave it on my desktop as a secondary choice if those were the only problems. Then I noticed how orrendously bad it performs, in particular for my case, that is someone who leaves many windows open all the time (like 100 windows of a browser like chromium). I couldn't use the system at all anymore, so I completely removed gnome from my system! Unfortunately currently xfce is buggy on debian unstable+experimental (like the window manager doesn't work, I don't know, I just noticed that the maintainer thought it was a good idea to close the bug report about this(reported by someone else)), so I'm currently using KDE. Without the semantic-blablabla which eats your cpu and hd space, it isn't bad!
(Log in to post comments)
extensions.gnome.org launches Posted Dec 2, 2011 6:45 UTC (Fri) by luya (subscriber, #50741) [Link] Then I noticed how orrendously bad it performs, in particular for my case, that is someone who leaves many windows open all the time (like 100 windows of a browser like chromium).100 opened windows from Chronium? Was each of them running heavy cpu intensive application like Flash? On which system?
extensions.gnome.org launches Posted Dec 2, 2011 14:47 UTC (Fri) by MisterIO (guest, #36192) [Link]
> 100 opened windows from Chronium?
Yes. > Was each of them running heavy cpu intensive application like Flash? No, _they_ weren't taking any cpu time at all (nor anything external like flash). > On which system? Debian Unstable/Experimental x86_64. Chromium v14, the last one working on Debian. v15 just goes "Aw, Snap" and dies an horrible death!
extensions.gnome.org launches Posted Dec 2, 2011 15:12 UTC (Fri) by Cato (subscriber, #7643) [Link]
Chromium uses a lot of RAM with many tabs in my experience - since GNOME 3 is no doubt more RAM intensive than GNOME 2, you may simply be running out of RAM with that many tabs loaded.
extensions.gnome.org launches Posted Dec 2, 2011 16:59 UTC (Fri) by Frej (subscriber, #4165) [Link]
No doubt? Are you sure? I *think* that 3.0 uses less ram (if 'intensive' ~ amount).... But i have no proof.
But neither do you ;)
extensions.gnome.org launches Posted Dec 2, 2011 18:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Hmm? My x86_64 CentOS 5 VM runs GNOME 2 in ~300MB. My Rawhide machine is close to ~200MB after booting runlevel 3. My F16 netbook is close to 150MB in the same state. Running X on top of that puts it over the VM's usage and I'm just running xmonad and xmobar. The lowest I've seen with Fedora (13 or 14 FWIW) is ~60MB on an i686 and pretty stripped down (no sendmail, sshd, iptables, etc.).
Now, of course, that's nothing compared to my FreeBSD box which boots in 30MB and rises to 40MB after running its jails which include nginx, postgres, a few fastcgi instances, git-daemon, and musicpd.
extensions.gnome.org launches Posted Dec 4, 2011 9:15 UTC (Sun) by Pawlerson (guest, #74136) [Link]
I wouldn't compare Fedora which is full of features to some minimalistic system. I bet you could have even less memory usage with Arch Linux.
extensions.gnome.org launches Posted Dec 2, 2011 17:41 UTC (Fri) by MisterIO (guest, #36192) [Link]
I have 12Gb of ram, so ram is definitely not the problem here.
extensions.gnome.org launches Posted Dec 5, 2011 10:42 UTC (Mon) by jezuch (subscriber, #52988) [Link]
> Debian Unstable/Experimental x86_64. Chromium v14, the last one working on Debian. v15 just goes "Aw, Snap" and dies an horrible death!
It's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647992 and looks like it's stalled.
extensions.gnome.org launches Posted Dec 2, 2011 8:17 UTC (Fri) by ovitters (subscriber, #27950) [Link]
Did you file a bug about the gnome-shell performance? Could you still test with GNOME 3.2 and file it (at https://bugzilla.gnome.org/)?
Even if you do not use it, I am still interested in ensuring it works for you :)
Make sure to mention your graphics card + driver as well.
extensions.gnome.org launches Posted Dec 2, 2011 14:53 UTC (Fri) by MisterIO (guest, #36192) [Link]
No, I didn't file a bug because my guess is that it's a design problem, that is not something that you can fix in any simple way. The problem is that every time that you select a virtual desktop, the windows in it are displayed in real time and that IMO eats huge quantities of cpu when you have many windows open, even if they're dormant (I may be wrong obviously, it's just a guess). Couldn't they take snapshots of the windows at some interval and display them? They could have been even cached that way. Is that impractical or maybe I'm missing something obvious for some reason? Even better, why not just show a little part of the title and nothing graphical at all? Not enough fancy stuff?
extensions.gnome.org launches Posted Dec 2, 2011 15:16 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
The scaling is done on the GPU, not the CPU. It's just displaying another copy of the texture that's aready in video memory.
extensions.gnome.org launches Posted Dec 2, 2011 17:45 UTC (Fri) by MisterIO (guest, #36192) [Link]
It does everything on the GPU? I guess that at least the management of the data structures to use those windows, to move them from the background to the foreground and anything else which isn't just showing an image is still done on the CPU, or maybe not?
extensions.gnome.org launches Posted Dec 2, 2011 18:20 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
I'm not quite clear on what you mean. The CPU certainly has to tell the GPU where to draw the textures, but that's not a significant amount of work.
extensions.gnome.org launches Posted Dec 3, 2011 15:07 UTC (Sat) by MisterIO (guest, #36192) [Link]
I was thinking about dropping this, since I doubt this can be interesting to anyone else other than myself, but, since I answered to another comment, here I am again. What I meant is that probably there is some other work done in the background by the gnome-shell which takes too much cpu time, not directly related to the simple act of just drawing textures.
extensions.gnome.org launches Posted Dec 3, 2011 21:20 UTC (Sat) by ovitters (subscriber, #27950) [Link]
Could be. We have a shell performance stats website at http://shell-perf.gnome.org/home. I guess we should check how it behaves with 100+ windows. Of course in a benchmark 100+ windows might be a few ms slower, but it should not be noticeable for a user (which is a 30% slowdown from what I heard).
extensions.gnome.org launches Posted Dec 5, 2011 8:55 UTC (Mon) by dgm (subscriber, #49227) [Link]
Maybe you mean it's done with OpenGL, so _hopefully_, _if_ you happen to have the right graphics card with the right driver, it _may_ be done in the GPU.
But how can this be related? Are you, MisterIO, showing all the 100 windows at the same time? Or maybe is GNOME Shell so dumb as to try to show all those scaled-down windows at the same time? Or worse, is it drawing them even if they are not shown?
extensions.gnome.org launches Posted Dec 5, 2011 12:06 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
If you don't have the right graphics driver with the right gpu, then right now you're not running Gnome Shell.
extensions.gnome.org launches Posted Dec 7, 2011 4:21 UTC (Wed) by k8to (subscriber, #15413) [Link]
That's the intent or the fact?
It seems like you could have a videocard and correct opengl driver that offers to do the operations but doesn't offer the performance. How is the capability tested?
extensions.gnome.org launches Posted Dec 7, 2011 4:28 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
How many opengl drivers do you think exist without the ability to scale textures?
extensions.gnome.org launches Posted Dec 7, 2011 20:24 UTC (Wed) by k8to (subscriber, #15413) [Link]
For what size textures?
extensions.gnome.org launches Posted Dec 7, 2011 20:38 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
2048x2048 on Intel <965 and Radeon <r500, 4096x4096 on everything else as far as I know.
extensions.gnome.org launches Posted Dec 7, 2011 20:48 UTC (Wed) by k8to (subscriber, #15413) [Link]
There exists a whole range of hardware that never could handle textures over 256x256.
extensions.gnome.org launches Posted Dec 7, 2011 20:53 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
I'm sure. I'm also sure that you're not running Gnome Shell on it.
extensions.gnome.org launches Posted Dec 3, 2011 12:45 UTC (Sat) by deepfire (subscriber, #26138) [Link]
I think you simply run out of VRAM on your GPU, which causes texture thrashing.
I have the same problem, with a relatively small (~20) windows on a 1920x1200 screen on a 128MB Radeon x800.
extensions.gnome.org launches Posted Dec 3, 2011 12:52 UTC (Sat) by deepfire (subscriber, #26138) [Link]
..just to put things into perspective:
1920x1200x4 = 9216000 bytes (all my windows are full-screen)
You can imagine how quickly my GPU runs out of its 128M VRAM..
extensions.gnome.org launches Posted Dec 3, 2011 15:00 UTC (Sat) by MisterIO (guest, #36192) [Link]
My GPU has 512 Mb of VRAM. I doubt that's the problem, but, if it is, then that's another example of bad design! I can't have 100 windows opened because they are all kept in VRAM memory to show them in realtime? Frankly, this doesn't make it look any better to me.
extensions.gnome.org launches Posted Dec 7, 2011 23:49 UTC (Wed) by tuna (guest, #44480) [Link]
Making a system that is optimized for having 10 windows instead of 100 windows open seems like a wise design decision. I am sure you have good reasons for having so many windows open, and if that is your requirement, maybe you should investigate a different DE.
extensions.gnome.org launches Posted Dec 8, 2011 0:09 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
at work we provide services for a couple thousand customers, a few years ago the company decided to re-write the application to be more modern, slick, etc.
During the development they repeatedly made decisions based on "90%+ of our customers don't need this feature". After a year and a half of development they announced that the new version was complete with great fanfare and got ready to roll the result out, only to discover that only 30 of our 2000 customers could use the new version of the product, because every other customer used one of those features that "90%+ of the customers don't need"
the fact that the statement "if you need that feature you should use a different DE" (or equivalent) is being said so frequently should be setting off alarms for people
This sort of thing is one of the big reasons why the simpler Microsoft Office competitors have not taken off, 90% of the people may not use 80% of the features, but the trouble is that it's not the same features that they don't need.
extensions.gnome.org launches Posted Dec 8, 2011 20:50 UTC (Thu) by sgros (subscriber, #36440) [Link]
So, you provided one (ok, two/three) examples of (supposedly) bad designs and that's OK, but the question is what does it prove except that there exist designs that are arguably flawed? How does that extends to Gnome Shell? Certainly there could be positive examples too, and we could end up enumerating both without any purpose.
In this particular case, two things are very interesting here, at least for me:
1. If you have a problem, then you fill a bug! In the end, if it is really a bug, bad design decision, or just a specific case not taken into account on purpose (but otherwise good design decision) is not known in advance and certainly not based on a single case.
2. To claim something is bad design simply based on a fact that _you_ have a problem, and repeat it every time you say something, is a bit too stretched and offensive (at least it sounds so to me)!
And I'm having open 12 Firefox windows and 107 tabs, which is now a lower value of the usual state, but I don't notice any slowdown. Could it be that the original poster really has 100 separate windows? But what is the purpose of such a large number of windows? BTW, I like gnome shell. There are problems and annoyances, but I believe that things will be better with each new release.
|
|||||||||||||