Re: Module Proposal: GNOME Shell

[Owen Taylor <otaylor redhat com>]

On Sun, 2010-04-04 at 11:57 +0800, Sam Spilsbury wrote:
> On Sun, Apr 4, 2010 at 11:50 AM, Owen Taylor <otaylor redhat com> wrote:
> > On Sat, 2010-04-03 at 18:41 +0200, Christophe Fergeau wrote:
> >> 2010/4/2 Owen Taylor <otaylor redhat com>:
> >> >  * 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.

> 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. ]

> 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