Re: GNOME Shell and GNOME-2.28

[Owen Taylor <otaylor redhat com>]

On Tue, 2009-05-12 at 11:29 +0100, Emmanuele Bassi wrote:
> On Mon, 2009-05-11 at 17:54 -0400, Owen Taylor wrote:
>   
> > Performance: gnome-shell needs to perform well enough that it
> >   will be usable for a wide range of people. Roughly speaking,
> >   this means that it needs to be competitive with Compiz in
> >   it's graphical demands and resource utilization.
> >   
> >   This will require work with X to determine what cards and drivers
> >   it can run on reasonably; to indentify bugs and performance
> >   problems, and get them fixed.
> 
> it'd be great if gnome-shell could give feedback to the clutter team as
> to where the performance issues of the shell are blocking on clutter
> itself. in the coming weeks, pre and post 1.0.0, the clutter team will
> work on stabilization and performance improvements. we've been profiling
> and instrumenting most of the stack but obviously real world use cases
> are the best platform for finding out eventual bottlenecks.

I haven't seen a lot of evidence that Clutter micro-optimization is
needed; getting a good sense of where bottlenecks are is hard with a
GPU/CPU combination, but they seem to be more GPU side.

(Some optimization possible around clipping and nested clips, I think.)

I'm actually more worried about large scale optimizations that could
require Clutter API changes. :-(

 - An integrated frame-synced update and display loop
 - Partial screen updates
 - Non-GPU based picking
 - Using the depth buffer or other means to reduce texture fetches 
   from obscured windows.

The integrated display loop is the first priority (and hopefully
possible to jury-rig onto an unmodified clutter), since it's hard to
quantify the situation without it, but beyond that, it's largely going
to be a question of figuring out how to measure what kind of performance
we are getting and where the bottlenecks are.

> > Accessibility: Full accessibility support is *not* a goal for
> >   the 2.28 version of gnome-shell, however, we need to make sure 
> >   that things are on track to get it there for 2.30/3.0. This
> >   will require review of accessibility support being developed
> >   for Clutter.
> 
> this is currently being worked on by the fine people at Igalia:
> 
>   http://lists.o-hand.com/clutter/2726.html
> 
> a talk on the subject has been proposed (and accepted) for this year's
> GUADEC. we're willing to host that project on clutter-project.org to
> allow easier integration with core and the rest of clutter's integration
> libraries.

Yeah, that's what I'm thinking that needs review. It's not clear to me
that the way GAIL was done is very applicable to clutter. The basic idea
of GAIL is that you can make a GTK+ API pretty much accessible by only
looking at the widgets in it, without a need for extensive application
involvement. So a loadable module But since so much of the meaning of a
Clutter interface is added by the application different approaches may
be needed.

- Owen