[Xorg] Damage/Composite + direct rendering clients

[Keith Packard]

Around 1 o'clock on May 18, Andy Ritger wrote:

> I'm debating whether it is better for the X server to not even know
> of the damage until it has completed in hardware, or if it is
> better to tell the X server as soon as the rendering has kicked off,
> and then require X to wait for completion only when it needs to
> use the drawable as a source.

I don't think we'll be able to know which is best without giving them both 
a try.  I was quite surprised at what method turned out best for the 
compositing manager -- one has been taught to avoid round trips at all 
cost, but the lowest latency was accomplished with an XSync call in the 
middle of the drawing loop.

Just goes to show that intuition and reality are often in conflict...

> > I just thought of another case here -- we want to allow for direct 
> > rendering compositing managers as well.  That will require inter-client
> > synchronization along the same lines...
> 
> This introduces the problem of how to get the pixmap data to the
> client efficiently.  That's a whole separate thread.

If the X server is drawing with GL, then the target GL drawing objects 
should be reachable by other GL applications.  If the X server is drawing 
through another mechanism, we'll need to create a way to label X pixmaps 
with GL names.

There are already two groups working on GL-based compositing managers, so 
we'll want to have this sooner, not later...

> Yes, if the composite manager grabs the server while updating the
> screen, then everything will be fine.  Your sample xcompmgr doesn't
> grab the server when updating the screen, and I expect many future
> composite managers will use xcompmgr as a starting point.

Fortunately, it's easy to add the grabs.  And, it might fix some other 
problems I've seen...

The existing compositing manager code needs to be replaced; it served as a
test bed for many different ideas, some of which negatively affected the
overall structure.

> That seems possible.  However, that seems like a lot to ask of all
> window managers.  Would common functionality like that be better
> contained within an X server extension?

Not an extension (there's no need), but surely a library would be useful.  
I've briefly looked into creating a library to help build compositing 
managers and composite-aware applications.

> > It could pretend the overlay port was busy for new apps and silently
> > translate an existing overlay application to textures. 
> 
> Interesting; this will require some more thought.

Yeah, it would be nice to just say "overlays are dead, use textures", but 
overlays remain an important option in many environments (better color, 
more features, higher performance).  So, I think we need to permit them, 
but find a way to cut over to textures where necessary.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040518/b800a227/attachment.pgp>