Re: Module Proposal: GNOME Shell

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

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.

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

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

> - Owen
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

Sam Spilsbury

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]