gtk clutter tearing

[Xavier Bestel]

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