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
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
