Re: Some considerations

On Wed, 2003-11-26 at 10:00, Brian Paul wrote:

> > Current apps don't use XSync to signal frame complete, but I think it will 
> > be relatively easy to retrofit into Qt and Gtk+.
> 
> Why do you need an explict end-of-frame marker?
> 
> In ordinary Xlib you can issue a bunch of drawing commands but you 
> won't necessarily see them until you either do an XSync() or try to 
> get an input event.
> 
> With ordinary X you can certainly see windows midway through 
> redraw/refresh.  So seeing partially updated windows in 
> compositor-based server isn't really a new thing.

Current toolkits - both GTK+ and Qt - double-buffer almost all drawing.
(GTK+ double buffers exposes by default, I think Qt is implemented more
widget-by-widget currently.) So, the only "partial update" that 
you typically see is half a CopyArea.

By controlling when updates happens, it's possible you can save the
memory for the double buffers. But the more important thing is to
get the window manager frame and the window contents updated together
when resizing. The most visible visual defect you see in X currently is
lagging during opaque resize.

Regards,
						Owen