Re: GNOME Shell and GNOME-2.28

[Emmanuele Bassi <ebassi linux intel com>]

On Tue, 2009-05-12 at 13:17 -0400, Owen Taylor wrote:

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

Rob Bragg committed today a fix for clipping rectangular areas in window
coordinates using glScissor -- used to make the pick a 1x1 area; this
sped up considerably the picking:

  http://bugzilla.openedhand.com/show_bug.cgi?id=949

> I'm actually more worried about large scale optimizations that could
> require Clutter API changes. :-(
> 
>  - An integrated frame-synced update and display loop

the 1.0-integration branch is using a master clock which makes all
animations vblank-limited using a MainLoop GSource that triggers redraws
and timeline advancements as part of the redraw loop. we're planning on
using this also to integrate the GStreamer video-sink inside clutter-gst
with the master clock so that every video frame upload is performed
within the redraw cycle.

hopefully, I'll merge this branch this week, as soon as some GLX bugs
have been ironed out.

>  - Partial screen updates
>  - Non-GPU based picking

these will require an API break; we have code that moves to a CPU-based
picking, but it's going to be 2.0 material.

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

yes, absolutely.

instrumentation and new profiling tools that reach the bottom layers of
the stack (drivers and GPU registers) are absolutely required to
identify the bottlenecks. we're working on that for the Intel GPUs.

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

it would also be good to get the a11y people involved to get their
feedback. part of the tools are being modified for the WebKitGtk support
so we might as well get people to review what's needed for Clutter to
work.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi, Senior Engineer        | emmanuele bassi intel com
Intel Open Source Technology Center     | http://oss.intel.com