Re: A possible problem with an external compositing manager

On Wed, 2003-11-12 at 15:04, Keith Packard wrote:
> Around 13 o'clock on Nov 12, Soeren Sandmann wrote:
> 
> > I thought of a potential problem with having all drawing routed though
> > an external compositing manager: Applications can no longer know for
> > sure that their drawing has actually reached the screen.
> 
> I hadn't thought of this, but it's certainly a valid point.  I can think 
> of several solutions, but none which is both efficient and compatible with 
> existing mechanisms.
> 

I'm not sure how valid it really is....

> I addressed this in the shadow frame buffer code by special casing 
> GetImage to sync contents to the screen before returning the data; we 
> can't really do that in this case without a lot of hacks.
> 

Semantically, we need to ensure the pixels returned are the
results of any rendering.  Unless the application is fetching
the root window, it will always get the expected result.

Remember, that displays are progressive scan: you don't
actually get photons out for a frame time as it is.

That they didn't happen to get to the screen for a frame time
because compositing happened to lag for some reason, seems
unlikely given current hardware speeds (at least if the
compositing is done in hardware), particularly with the
damage facilities minimizing the number of pixels to
be recomposited.

So is this a real issue?

And is the case of getting the root window and having it
inconsistent from the state of the pixels inside the windows
a case that is worth worrying about?  After all, we're
modifying the pixel values by definition for the eye candy.
                         - Jim




-- 
Jim Gettys <[email protected]>
HP Labs, Cambridge Research Laboratory