Re: A possible problem with an external compositing manager

Owen Taylor <[email protected]> writes:

> While it is theoretically possible to animate at a faster rate
> than the time it takes to go:
> 
>  app ==(draw)==>  server
>                   server ==(damage)===> cm
>                   server <=(composite)= cm
>                   server <=(message)=== cm
>  app <=(message)= server
> 
> It's really hard to get right, since the app has to (in essence)
> estimate the rate at which each step gets performed and self-throttle
> at the minimum of those rates. In general, I think it's better to keep
> things simple, and accept the inequality:
> 
>  frame_time > server/app roundtrip time

I would hope we could do better than that inequality.

As far as I can see it isn't really that hard to get right if the
application can measure the time it takes from the frame is generated
until it is drawn on screen (or sent on to the video card).

>  "Tell me when any damage to window W that you recieved prior
>   to this message has been sent to the display, with cookie C"
> 
>  "The damage referenced by cookie C is done"
> 
> As far as I can see, unless you can figure out a way to get rid 
> of the per-frame roundtrip, you can't do significantly better than 
> this. (My assumption is that the cm is local to the server ... it's
> the only architecture that makes sense.)

With the cookie scheme you suggest above, if the response had a
timestamp from the X server, it would be possible to maintain a pretty
good estimate of the frame rate that the server can sustain. Wouldn't
just throttling to that give pretty good results?


Søren