Updates to GLX_EXT_texture_from_pixmap

[James Jones]

On Thursday 23 March 2006 08:32 am, Brian Paul wrote:
> I haven't had time to follow this discussion too closely but I
> guess my take on it is that no synchronization between
> reading/drawing is really needed at all.
>
> When the programmer really wants "flicker-free" drawing (i.e. no
> displaying of incomplete rendering) they'll use double-buffering.
>  The compositor will texture from the front color buffer while
> the app draws to the back buffer.

This is all fine if the composite is a single, atomic operation.  In 
several interesting cases it's not.  What if the composite manager 
wants to do some fancy multi-pass algorithm to composite the 
windows, and in between passes, the composite manager gets 
scheduled out, the application gets scheduled in, and swaps again?  
What if there are multiple overlapping regions that need updating, 
and halfway through the update, one of the windows swaps, leaving 
different regions of the same drawable displaying differing frames?  

These sort of artifacts are ugly, worse than traditional 
non-sync-to-vblank tearing.  Playing transparent movies over top of 
an animated app leaves you with the intersecting rectangle of the 
movie and the app being updated at a different rate than the rest 
of your movie window and app window.  Same thing when playing 
games.  Even if your game appears to occlude the entire desktop, 
applications running behind it can now cause composite operations 
on small portions of the game window.  These problems definitely 
need to be solved.  I am advocating they be solved in some other 
way than introducing synchronization semantics in the 
GLX_EXT_texture_from_pixmap specifiction.

It should not be necessary to introduce the concept of a frame into 
Xlib, for the reasons you describe below.  It does seem necessary 
to introduce a FAST method of making composite operations atomic 
across the surfaces they need to access.  Keith originally proposed 
using server grabs for this.  This works, but it seems too 
heavyweight.

Thanks,
-James

> For Xlib rendering into a pixmap we don't have an explicit
> "end-of-frame" command (no such thing in Xlib).  But the end of
> drawing can be implied by the app calling XSync() or an
> XGetEvent()-type of function since those force any pending
> rendering to be completed.  But even those functions don't name a
> drawable.
>
>
> The X server could either:
> 1. Automatically double-buffer all window pixmaps.  Upon
>     XSync()/XGetEvent() copy the back color buffer to the front
>     for any pixmaps that have been written to since the last
>     back->front copy.
>
> 2. Do nothing special; just texture from the pixmap whenever it
> wants. If the app isn't finished drawing you'll get an incomplete
> rendering on screen.  But that's basically what happens with X
> today anyway.  If the hardware can'd do simultaneous drawing to
> and texturing from a particular buffer, go with option 1.
>
> -Brian
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg