gtk clutter tearing

Hi,
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?

Thanks
Mark.

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

After this I think things should look fine in Clutter when app does
things right. E.g. panning in normal applications can still tear though
because Gtk doesn't have any support for Vsync. This is not really
fixable due to how Gtk painting is arranged, parts of the window are
painted in application callbacks. If application callback is fast
enough that it gets into same boxed damage event from X server (to
compositor) as the internal Gtk pannable area scroll, there's no
tearing, if it gets drawn later, then update for that part of the window
goes to screen on next compositor screen update.


- Eero

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

I just tried the Bounce Evolution game and that synchs perfectly so I guess this means full screen OpenGL works fine (as it does with general transition effects). Does this mean that full screen clutter will work well too?

Would the Qt 4.6 Animation Framework work smoothly non-fullscreen?

What are the chances of this 'bug' being a high priority and getting fixed soon? I guess that smooth non-fullscreen animation is something many developers would want and end-users would expect to see.

I'll get off and file this bug...

Cheers
Mark

Eero Tamminen on 12/29/2009 09:17 AM wrote:
> because Gtk doesn't have any support for Vsync.

Gtk doesn't need to support Vsync. Qt won't magically fix this problem
either.

Only the compositor needs to support Vsync. Once it does then *all* 2D
operations will be tear-free. Gtk, Qt, terminal-based, etc.

Hi,

ext Michael Cronenworth wrote:
> Eero Tamminen on 12/29/2009 09:17 AM wrote:
>> because Gtk doesn't have any support for Vsync.
>
> Gtk doesn't need to support Vsync. Qt won't magically fix this problem
> either.
>
> Only the compositor needs to support Vsync. Once it does then *all* 2D
> operations will be tear-free. Gtk, Qt, terminal-based, etc.

Incorrect. If application updates to it's composite buffer aren't
in sync with the compositor display updates, there's obviously
a possibility for tearing.

In practice, if application callbacks paint their own parts fast enough
after Gtk does window scroll, they get in to same boxed XDamage event
and usually everything looks fine. If they don't, there's tearing.
If Gtk happens to draw to its backbuffer while HW is compositing
(as requested by compositor), there's also tearing (whether it's visible
to user, depends on what's drawn). I think compositor does either
input or server grab while compositing, so this might not be a problem.
Former can be though.

In summary, all of these three steps need to be synchronized for
tearing to be completely eliminated:
app -> composite buffer -> framebuffer -> LCD

Synchronization means waiting / extra buffers so it will slow down
screen updates to some extent. Any extra copying done for this would
have a large effect on performance because the device is memory
bandwidth constrained (like all computers nowadays), buffer swapping
is better in this respect. But extra buffers mean increased memory
consumption (800x480@16-bit RGB surface is 750kB, at 32-bit RGBA
it's 1.5MB).


- Eero

El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
> This is not really
> fixable due to how Gtk painting is arranged, parts of the window are
> painted in application callbacks.

This is not totally correct. Application callbacks can only cause GTK+
to *invalidate* regions. In sane code, redrawing *never* happens in a
user callback but only in expose event callbacks, which are triggered by
GTK+ *only* when the time for redrawing comes.

Nevertheless, there are still issues with GTK+ and synchronization of
events. See [1] and [2] for a good explanation of these.

Claudio

[1] http://blog.fishsoup.net/2009/05/28/frames-not-idles/
[2] http://blog.fishsoup.net/2009/06/02/timing-frame-display/

Hi,

ext Claudio Saavedra wrote:
> El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
>> This is not really
>> fixable due to how Gtk painting is arranged, parts of the window are
>> painted in application callbacks.
>
> This is not totally correct. Application callbacks can only cause GTK+
> to *invalidate* regions. In sane code, redrawing *never* happens in a
> user callback but only in expose event callbacks, which are triggered by
> GTK+ *only* when the time for redrawing comes.

Application (expose event) callbacks implement painting for
application's own widgets and treeview cell renderers.

But where inside the application process they happen (app or Gtk code)
is not so important. The issue is that Gtk (AFAIK) has no mechanism to
synchronize this drawing with the compositor and doesn't offer
applications any mechanism for it either. If painting/redrawing
takes too long (there's some delay between the X draw commands due
to what application does internally), it doesn't go the the same boxed
XDamage event to the compositor.


- Eero

On Wed, 2009-12-30 at 14:44 +0200, Eero Tamminen wrote:
> Hi,
>
> ext Claudio Saavedra wrote:
> > El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
> >> This is not really
> >> fixable due to how Gtk painting is arranged, parts of the window are
> >> painted in application callbacks.
> >
> > This is not totally correct. Application callbacks can only cause GTK+
> > to *invalidate* regions. In sane code, redrawing *never* happens in a
> > user callback but only in expose event callbacks, which are triggered by
> > GTK+ *only* when the time for redrawing comes.
>
> Application (expose event) callbacks implement painting for
> application's own widgets and treeview cell renderers.
>
> But where inside the application process they happen (app or Gtk code)
> is not so important. The issue is that Gtk (AFAIK) has no mechanism to
> synchronize this drawing with the compositor and doesn't offer
> applications any mechanism for it either. If painting/redrawing
> takes too long (there's some delay between the X draw commands due
> to what application does internally), it doesn't go the the same boxed
> XDamage event to the compositor.

AFAIK GTK+ redraws are double-buffered, so if it takes too long to
redraw a frame it's simply delayed until the next one.

Xav

Hi,

ext Xavier Bestel wrote:
>> But where inside the application process they happen (app or Gtk code)
>> is not so important. The issue is that Gtk (AFAIK) has no mechanism to
>> synchronize this drawing with the compositor and doesn't offer
>> applications any mechanism for it either. If painting/redrawing
>> takes too long (there's some delay between the X draw commands due
>> to what application does internally), it doesn't go the the same boxed
>> XDamage event to the compositor.
>
> AFAIK GTK+ redraws are double-buffered, so if it takes too long to
> redraw a frame it's simply delayed until the next one.

That double buffering overhead is used to get rid of flickering
resulting from successive clear+draw operations, (AFAIK) it's not
whole window buffer (for obvious memory usage reasons), so it's not
relevant for the tearing issue.


- Eero

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*. My own apps are tear free until I turn off..
you get the point, I hope.

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