RandR 1.4 restart
sandmann at cs.au.dk
Tue Mar 1 11:12:14 PST 2011
Ville Syrjälä <ville.syrjala at nokia.com> writes:
> On Mon, Feb 28, 2011 at 05:29:56PM -0800, ext Keith Packard wrote:
>> Ok, let's try to get a bit of protocol review, then look at the library
>> API, then the server internal APIs and finally the server
>> implementation. Most of the code already exists, so this shouldn't take
>> a terribly long time.
>> I've cleaned up the protocol a bit, reducing the changes so that we've
>> got only one 'set' and one 'get' request, each of which do 'everything'
>> except deal with output properties. The separate requests to set and
>> query the sprite transforms are gone.
>> For the library changes, I'd like to know is whether I should emulate
>> the new SetCrtcConfigs interface using old requests on old servers. That
>> would involve duplicating a bit of structure from the insides of the X
>> server, but would mean that applications could switch to the new
>> interface and not worry about preserving compatibility with the old.
>> Here's a diff from 1.3.2 of just the protocol specification. Please see
>> if this looks reasonable from a protocol perspective.
> So what about also allowing windows to use the scanout pixmaps as their
> backing pixmap? I'm mainly interested in something that would allow
> unredirected 32bpp windows on a 16bpp screen.
Presumably the main use case for this is fullscreen video. IMO, we need
to move to a model where
- The backing store for a window is managed by the compositing
manager, and not by the X server.
- Applications send update requests directly to the compositing
manager (through ClientMessages or the like) in the form of Picture
IDs plus coordinates for a position where those pictures are to be
- Applications either tell the compositing manager what format the
window pixmap should be, or they let the compositing make that
decision itself based on the root format and/or the formats of the
In this model, toplevel windows would be InputOnly and not InputOutput
as they are now.
- Completely tear-free updates because the compositing manager can
delay updating the window pixmaps until the application signals that
it has finished drawing a frame. (We may need client-visible
refcounts on pictures for this to work).
- With the RandR 1.4 SetCRTCPixmap, almost all the current copying
goes away. For reference, here are the copies that may currently
- Application draws into offscreen pixmap
- Application draws offscreen pixmap into redirected window
- Redirected window is copied onto redirected window frame (if the
frame has a different depth than the window)
- Redirected window frame is copied onto offscreen pixmap by
- Offscreen pixmap is copied into shadow framebuffer by X server
- Shadow framebuffer is copied into real framebuffer
In the new model, the application draws into offscreen pixmaps,
which are copied into backing pixmaps, which are copied directly
into the (eventual) framebuffer. Enterprising compositing managers
could even try to reuse the framebuffer as backing store for the
parts of windows that are visible.
For full-screen video in particular, if Render were to gain support for
YUV formats, the advantages are significant:
- The video player could submit YUV pictures directly to the
compositing manager, which could then decide how to best scale it
and convert to RGB. An obvious option would be scanning them out
directly if the window is fullscreen and the hardware supports it.
- The backing pixmap could be updated with just the blocks that
actually changed since the last frame (as provided by the video
The net result would be a huge reduction in memory bandwidth for video
With a scheme like this, the Composite extension itself would become
simply a way to support legacy applications since window redirection
doesn't really mean anything for InputOnly windows.
More information about the xorg-devel