On Sun, Apr 4, 2010 at 12:16 PM, Owen Taylor <[email protected]> wrote: > On Sun, 2010-04-04 at 11:57 +0800, Sam Spilsbury wrote: >> On Sun, Apr 4, 2010 at 11:50 AM, Owen Taylor <[email protected]> wrote: >> > On Sat, 2010-04-03 at 18:41 +0200, Christophe Fergeau wrote: >> >> 2010/4/2 Owen Taylor <[email protected]>: >> >> > * Virtually all machines produced currently, or in the last 5 years >> >> > have sufficiently powerful graphics to meet our needs. In some >> >> > cases, free software drivers that can access this hardware >> >> > don't exist are or still in an early stage. But we can't offer >> >> > someone with shiny new hardware a desktop that looks like they >> >> > have a 10 year old machine. >> >> > >> >> > - Buy hardware from friendly companies >> >> > - Fix the free drivers for other hardware >> >> > - If necessary and desired, offer users ways to install >> >> > non-free drivers before they get to the desktop. >> >> >> >> I've tested gnome-shell last week on a (not too recent) machine where >> >> compiz works well enough and gnome-shell was really slow. I guess this >> >> machine falls in the "free driver that needs fixing category", but >> >> given what other colleagues experienced with a few years old machines, >> >> I'm under the impression this situation is quite common. >> > >> > There is very little that GNOME Shell does that makes it *inherently* >> > more demanding than Compiz. >> >> Actually, there is. >> >> Mutter runs on Clutter, which requires full scene-graph calculations >> and currently cannot handle damage events correctly the last time I >> checked (since it redraws the whole screen). > > Clutter-1.2 has some support for partial-stage redraws. See: > > https://bugzilla.gnome.org/show_bug.cgi?id=611838 > > For hooking that up to Mutter. Though partial-stage redraws are more > important for power-consumption than for raw performance, since being > able to animate just a little bit changing at a high frame isn't that > interesting - we need to be able to do our full-screen animations at a > high frame rate as well. >
That's good. Full screen redraws on every frame cause ridiculously high CPU usage - to see what I mean, write a compiz plugin which does damageScreen (s); on every damage event. >> The other problem with GNOME-Shell is that the vast majority of it >> runs under a dynarec with javascript, which, although fast, can never >> be faster than optimized C/C++ code. > > The large majority of code that runs *for each frame* is written in C. > The fact that some Javascript runs when you click on a button is pretty > much irrelevant to the performance of the shell. But yes, I can't really > deny the theory that it would be (just slightly) faster if everything > was written in C. > > [ I'm sure someone has a benchmark somewhere of a Javascript JIT beating > out compiled C code by using run-time statistics or by having a > smaller code size by not compiling never-reached code branches. > It's never going to be the normal case. And doesn't matter. ] It matters a _lot_ for startup time (which is a problem for ubuntu). Opening compiled libraries with dlopen is slow enough already - loading an entire javascript JIT compiler, then parsing all the code, then executing it on first pass is _still_ slow because the optimization doesn't happen until later. I've measured startup times of the entire Shell stack of about 30 seconds, and this is an EeePC 900 - underpowered yes, but not slow out of the box. Compared to mutter, which starts in about 3 seconds (and as you said, is all implemented in C), I see this as a big problem (a problem created by trying to couple far too much into the window manager process). I run compiz 0.9 on this machine, and I can load about 50 plugins written in C++ sequentially using dlopen () with debugging symbols faster than I can load gnome-shell. > >> Keep in mind too, that there there is a heck of a lot of code that >> within the window manager process, which all must be dynamically >> loaded - and considering that lot of the I/O stuff has not been >> multi-threaded yet, this can be blocking on rendering as well. > > I'm much more concerned about rendering blocking on I/O than I/O > blocking on rendering. The reason to move I/O out of the main thread > isn't to make the I/O faster but to be able to keep things animating > smoothly and redrawing even when a request for data from the disk is > outstanding. > >> >> I really hope things will get much better when release time comes, but >> >> for now, saying "any 3D hardware from the last 5 years will do" is a >> >> bit misleading since it hides the fact that gnome-shell seems more >> >> demanding on hardware/drivers than other applications (eg compiz). Or >> >> maybe it's the other way round and drivers were optimized for compiz, >> >> but it's still worth being as transparent as possible wrt current >> >> state of 3d performance expected by gnome-shell. >> > >> > As described in the roadmap, the necessary first step is obtaining >> > numbers. >> >> In terms of 3D drivers, I think we can discount the NVIDIA one here - >> it is optimized for the "lazy binding" code path, which compiz used to >> use. Strict binding is generally a lot slower on this driver [as we >> found when we changed the binding system in compiz 0.9]. > > There have been some changes in how binding is done in Clutter 1.2, but > generally, both in 1.0 and 1.2 it is rebinding the texture only when the > pixmap contents change. Which should be as lazy as permitted by the > texture_from_pixmap specification. > >> In terms of virtualized drivers, Owen is correct in saying that they >> are optimized for the binding method compiz uses, although as far as >> we can tell clutter and kwin don't implement the >> EXT_texture_from_pixmap specification quite as correctly as they >> could, so that is why you see slowness or rendering issues on virtual >> machines. > > I'm not aware of any case where Clutter isn't following the > texture_from_pixmap spec at the moment, though there have been lots of > different conversations about the area, so I may well have forgotten > something that I noticed or that was pointed out to me earlier. > > - Owen > > > -- Sam Spilsbury _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
