Re: A possible problem with an external compositing manager

Keith Packard wrote:
> Around 22 o'clock on Nov 12, Soeren Sandmann wrote:
> 
> 
>>It is not GetImage I am worried about. It is the fact that
>>applications don't know how when their drawing reaches the screen.
> 
> 
> That's already very true today -- the X server doesn't wait for the 
> graphics engine to finish drawing before executing the next request; the 
> current kludge that many applications use is to use GetImage to fetch a 
> pixel from the target drawable; current rendering code doesn't try to 
> figure out what that pixel will be when the rendering is finished, instead 
> it simply waits for the engine to go idle before reading the frame buffer.
> 
> 
>>Each XSync() has the effect of waiting until the server has actually
>>drawn the previous frame. This:
> 
> 
> Not true; the XSync will wait only until the X server has queued the 
> rendering operations to the video card.  Then there is the delay between 
> when the frame is drawn to video memory and when it is actually visible on 
> the screen.  The GetImage trick reduces arbitrary graphics card latency to 
> bounded retrace lacency.
> 
> Assuming our compositing manager can do screen updates within some 
> reasonable time bound, the GetImage trick will do the same here, with 
> perhaps a longer lag.

It really is a terrible way to synchronize with the hardware...

I remember working out once apon a time a trick that somehow provoked the X 
server to send be back an asynchronous notification that a certain point in 
the protocol stream had been reached - maybe somehow by provoking an event? 
That code is long gone, though others have probably done the same thing a 
dozen times.

That was the closest I was able to get to non-blocking synchronization - only 
at the protocol level, though, there was no way to extend it to be equivalent 
to the getimage hack.

Keith