[maemo-developers] Clutter in Fremantle (Alpha SDK)

[From: Kimmo Hämäläinen]

On Tue, 2009-03-17 at 18:04 +0100, ext Henrik Hedberg wrote:
> Kimmo Hämäläinen wrote:
> > On Tue, 2009-03-17 at 08:37 +0100, ext Henrik Hedberg wrote:
> 
> >>     Is this somehow related to this statement: "It is assumed that we 
> >> will have only one OpenGL drawing context, and thus a single process 
> >> running in the system will be using Clutter at a time. This process will 
> >> be the window manager and the implementor of all challenging graphical 
> >> UI effects on the screen." [2]
> > 
> > This we have assumed in the design, but it does not mean that multi-
> > context does not work. As Kate has already proven, multi-context works.
> > But as long as you have hildon-desktop running in the background, you
> > will not render directly to the screen even if you use
> > Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When
> > hildon-desktop is running, it is the only one drawing on the screen
> > (with the exception of XVideo). So, killing hildon-desktop is the only
> > way to get direct rendering to the screen at the moment. (We might have
> > something more elegant for this in the future...)
> 
>     Could you clarify what does this mean in practice? Is the 
> performance of 3D rendering significantly slower in applications, for 
> example? I suppose that even if off-screen rendering is used it is still 
> hardware accelerated. Thus, compositing in window manager level should 
> not be a big issue, and we can live with that (for now) if everything 
> just work fast enough. Who needs direct rendering anyway. :)

Keeping the compositor around has some performance impact, because after
the application draws to an offscreen pixmap (the window), the X server
sends Damage events (saying "this part of the pixmap changed") to
hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in
a OpenGL texture and draw it to the screen. So, there is some extra
delay (maybe 10-25ms) after the application's drawing is visible. 

Second implication is that you cannot use HW accelerated zooming and
moving of textures for the whole graphical pipeline. You can use it for
drawing into your window, but when hildon-desktop draws to the screen,
it cannot use it (e.g. it cannot say "move this content to there"). It
will just get a big damage area that is updated by updating the OpenGL
texture content.

Third implication: to save memory, we are using the texture-from-pixmap
GL extension to allow the X server and 3D HW share the pixmap data. This
means that while 3D HW is accessing the pixmap data (while transferring
it to the 3D chip), X server cannot access it. Thus, while the
compositor is updating the screen, it is slowing down X drawing.
However, it's not mandatory to use texture-from-pixmap, but then you are
paying the price in increased RAM usage.

BR; Kimmo

> 
>     BR,
> 
>     Henrik
>