Re: A possible problem with an external compositing manager

[ Resend, ran into some problems with mail to freedesktop.org the first time ]

On Wed, 2003-11-12 at 15:19, Jim Gettys wrote:
> 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?

I don't think GetImage on the root window needs to show the final
contents, and I think GetImage on redirected windows should get
the bits from the redirect buffer. So, that's not really a concern.

But I do think that knowing (as well as possible without graphics
card pipeline flushes) when your bits hit the screen is going to
be useful for animation... drawing stuff to the X server as fast
as possible until the pipeline fills and blocking on the next
drawing command is not really a good way to to handle things - 
a) you are blocked b) you are lagged by the depth of your pipeline.

It's worth diagramming out some of the common scenarios:

 - Application displays animation in response to mouse motion
   (rubber-banding, say)

 - Application is all about displaying an animation (video
   player, say)

 - Application is updating a display while doing some other
   CPU intensive process that shouldn't block on when the
   blocks (OS installer drawing a progress bar when you are 
   doing a remote install on a S/390 in Germany)

 - Opaque resize (assume the CM and WM are the same process)

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

So, the notification when compositing finishes *is* useful; however,
I think it can be done well without any changes to the DAMAGE 
or COMPOSITE extensions. The simplest way is to define two
client messages:

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

Regards,
						Owen