Re: Module Proposal: GNOME Shell

[Sam Spilsbury <smspillaz gmail com>]

On Sun, Apr 4, 2010 at 12:16 PM, Owen Taylor <otaylor redhat com> wrote:
> 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.
>

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