Enhancements for Render composite request

[Keith Packard]

The render composite request has a couple of glaring failures:

 1) Only one rectangle per request. Apps generate a lot of protocol,
    the server spends a lot of time decoding requests and the driver
    has to merge requests back together to hand more than one polygon
    to the hardware. It's interesting that exa (and hence uxa by
    derivation) have a poly-rectangle composite operation in their
    driver interface.

 2) No vblank synchronization. Anyone wanting to double buffer 2D apps
    has no way of avoiding tearing. I'd like this inside the X server
    to make updates under a RandR transform sync to vblank.

As operation 1) is already supported by the EXA API, and can be emulated
in DIX by executing multiple one-rectangle composite requests, this
seems easy to add to the protocol in a completely compatible fashion:

COMPOSITERECT	[
			src-x, src-y:	INT16
			msk-x, msk-y:	INT16
			dst-x, dst-y:	INT16
			width, height:	CARD16
		]

CompositeRectangles

	op:		PICTOP
	src:		PICTURE
	mask:		PICTURE or None
	dst:		PICTURE
	rects:		LISTofCOMPOSITERECT

	This request is equivalent to a sequence of Composite requests
	using the same op/src/mask/dst values and stepping through
	rects.

It seems like operation 2) should be an option on the picture object;
set a sync mode on the picture and all operations would be covered by
that mode. It would be 'best effort', so that drivers not supporting the
sync mode would simply skip it. The question is how fancy this option
should be; in the simple case, we'd make it just avoid tearing, more
complex cases could involve having sequential operations to the same
picture wait for a specific frame number. I'd love to have comments on
precisely which 'swap modes' would be useful here.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20090825/8bcf2daa/attachment.pgp