On Tue, 25 Aug 2009 10:34:21 -0700 Keith Packard <[email protected]> wrote:
> 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. Avoiding tearing is the most important thing here, but if you're writing a media app you'd probably want to be able to specify an interval, e.g. never swap more than N frames/second. Assuming you can find a mode that's a multiple of the framerate you want, this is a handy feature. Check out the SGI_swap_control and OML_sync_control extensions for more details on what GL expects (OML adds a few more features like a swap counts, swaps on specific frame counts, etc.). -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
