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.
--
[email protected]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
