Updates to GLX_EXT_texture_from_pixmap

[Deron Johnson]

It doesn't matter if the composite manager gets swapped out while
holding the lock. As long as any clients attempting to draw to the
drawable, including swap the drawable, are blocked while the lock is
held then everything should be okay.

I would really advocate trying a concrete experiment with this.
Implement the ClientSleep approach for X clients and blocking of direct
rendering, and provide a way to conditionally turn off the blocking.
Then give me a copy of it to run with LG. I can try it both with
and without blocking to see what it looks like.

James Jones wrote On 03/23/06 13:39,:
> 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
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg