Re: A possible problem with an external compositing manager

Keith Packard <[email protected]> writes:

> 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 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.

It is not GetImage I am worried about. It is the fact that
applications don't know how when their drawing reaches the screen.

An application that wants to draw a frame of an animation as often as
possible can currently do this:

(A)     Draw frame
        XSync()
        Draw frame
        XSync()
        ...

Each XSync() has the effect of waiting until the server has actually
drawn the previous frame. This:

(B)     Draw frame
        Draw frame
        Draw frame
        Draw frame
        ...

would swamp the X server with updates. Note this is an animation that
at any point in time has a frame it wants drawn, a continuous
animation, as opposed to an animation with a discrete set of frames
like a video playback.

If you try (A) in the presence of a compositing manager, each XSync()
would only make sure that a DamageNotify had been sent to the
compositing manager, not that the pixels were actually drawn to the
screen. This means the application would try to generate too many
frames which is a waste of CPU that would be taken away from the
composting manager if they were on the same computer.


Søren