gtk clutter tearing

On Tue, 2009-12-29 at 16:17 +0100, Tamminen Eero (Nokia-D/Helsinki)
wrote:
> Hi,
>
> ext Mark Clarkson wrote:
> > I have made a simple animation using a clutter timeline with clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the animation plays making the animation look terrible.
> >
> > I have tried none, dri and glx values for the CLUTTER_VBLANK environment variable but this seems to have no effect at all.
> >
> > Is there a way to fix this?
>
> Screen update isn't yet synched to LCD refresh. Please file a bug about
> it to bugs.maemo.org (it needs support from kernel display driver, X
> server, SGX driver, Clutter and hildon-desktop compositor, but I guess
> you could file it against Official platform -> Core -> X).

Don't hold your breath with this one. At the moment it seems a proper
vsync support is not going to be implemented in Maemo 5. There is a
possibility to use a vsync even now, but the implementation is not good
enough: if you enable the current vsync, the OpenGL application is
blocked on glSwapBuffers until vsync comes, which prevents the
application to prepare the next frame (and drops FPS too low).

I think doing like Bounce does is the best you can do: use fullscreen
window and disable the compositor (in hildon-desktop). Recent
hildon-desktop versions disable compositing automatically for fullscreen
windows, unless you use HildonStackableWindow (which requires the
sliding animation).

-Kimmo

Hi,

ext Michael Cronenworth wrote:
> Eero Tamminen on 12/30/2009 04:09 AM wrote:
>> Incorrect.
>
> I guess there's some illegal black magic happening in-between compiz and
> apps regardless of UI toolkit libraries. Apps such as dasher that
> present rectangles and text at fast speeds do not present any tearing
> when I have the *compositor* set to vsync. Firefox with the SmoothWheel
> extension for liquid smooth scrolling is tear free until I turn vsync
> off on the *compositor*.

If the related toolkit updates gets into same boxed XDamage event going
to the compositor and compositor blocks X updates to the composite
buffer while compositing it to screen, you don't get tearing. In
practice this may be enough, especially on faster machines, but
I think it's more due to fortunate co-incidences than something
really being guaranteed by the (current Gtk) toolkit.


> My own apps are tear free until I turn off..
> you get the point, I hope.

Try for example pannable Gtk treeview with your own cell renderer
and add some suitable wait into that renderer to make sure that your
renderers' window update gets timewise separated from rest of
the treeview update and see whether you get tearing.


> Of course, I could get into a technical acronym-fest with you, but that
> wouldn't be very helpful as real world examples would.
>
> > If application updates to it's composite buffer aren't
> > in sync with the compositor display updates, there's obviously
> > a possibility for tearing.
>
> I don't think you understand how X works. :)

Hm. Do you? :-)


- Eero

Kimmo Hämäläinen wrote:
> Recent
> hildon-desktop versions disable compositing automatically for fullscreen
> windows, unless you use HildonStackableWindow (which requires the
> sliding animation).

I wonder what happens to translucent information messages (charger
attached/removed, ...) in fullscreen SDL applications, are these not
shown when compositing is off or are they done in different way and
still shown?

Frantisek

Hi,

ext Frantisek Dufka wrote:
>> Recent
>> hildon-desktop versions disable compositing automatically for fullscreen
>> windows, unless you use HildonStackableWindow (which requires the
>> sliding animation).
>
> I wonder what happens to translucent information messages (charger
> attached/removed, ...) in fullscreen SDL applications, are these not
> shown when compositing is off or are they done in different way and
> still shown?

hildon-desktop automatically switches to composited mode when needed.

(Making this transition without a temporary user visible visual
"glitch", has taken quite a bit of effort, AFAIK including fixes to
upstream X server too.)


- Eero

On Mon, 2010-01-11 at 18:58 +0100, Tamminen Eero (Nokia-D/Helsinki)
wrote:
> Hi,
>
> ext Frantisek Dufka wrote:
> >> Recent
> >> hildon-desktop versions disable compositing automatically for fullscreen
> >> windows, unless you use HildonStackableWindow (which requires the
> >> sliding animation).
> >
> > I wonder what happens to translucent information messages (charger
> > attached/removed, ...) in fullscreen SDL applications, are these not
> > shown when compositing is off or are they done in different way and
> > still shown?
>
> hildon-desktop automatically switches to composited mode when needed.
>
> (Making this transition without a temporary user visible visual
> "glitch", has taken quite a bit of effort, AFAIK including fixes to
> upstream X server too.)

Yes, Daniel Stone did an impressive job to get this to work. We can
switch between compositing/non-compositing mode without requiring the
applications to repaint their windows.

-Kimmo

>
>
> - Eero

Many thanks for the information Kimmo. At least I know which way to go now - this seems to be similar to how iPhone apps behave and I guess this will allow me to port to other OpenGL devices quite easily.

----- Original message -----
> On Tue, 2009-12-29 at 16:17 +0100, Tamminen Eero (Nokia-D/Helsinki)
> wrote:
> > Hi,
> >
> > ext Mark Clarkson wrote:
> > > I have made a simple animation using a clutter timeline with
> > > clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the
> > > animation plays making the animation look terrible.
> > >
> > > I have tried none, dri and glx values for the CLUTTER_VBLANK environment
> > > variable but this seems to have no effect at all.
> > >
> > > Is there a way to fix this?
> >
> > Screen update isn't yet synched to LCD refresh.  Please file a bug about
> > it to bugs.maemo.org (it needs support from kernel display driver, X
> > server, SGX driver, Clutter and hildon-desktop compositor, but I guess
> > you could file it against Official platform -> Core -> X).
>
> Don't hold your breath with this one. At the moment it seems a proper
> vsync support is not going to be implemented in Maemo 5. There is a
> possibility to use a vsync even now, but the implementation is not good
> enough: if you enable the current vsync, the OpenGL application is
> blocked on glSwapBuffers until vsync comes, which prevents the
> application to prepare the next frame (and drops FPS too low).
>
> I think doing like Bounce does is the best you can do: use fullscreen
> window and disable the compositor (in hildon-desktop). Recent
> hildon-desktop versions disable compositing automatically for fullscreen
> windows, unless you use HildonStackableWindow (which requires the
> sliding animation).
>
> -Kimmo
>
>