Talk:X video extension
|WikiProject Computing / Software||(Rated Start-class, Low-importance)|
No, it doesn't depend on compositing at all
The section about compositing window managers is simply wrong.
It's true that Xvideo will sometimes use colour-key compositing -- if the video hardware wants to do things that way. But this is largely down to hardware or driver limitations, and nothing to do with the window manager whatever. I wish I had some external document to cite, other than maybe the Xvideo protocol specifications (which doesn't, in fact, mention colour-key compositing anywhere).
The Xvideo extension was originally designed to present output from video sources like cameras as part of the X window system; rendering of software generated video was added later, through the XPutImage and XShmPutImage requests. If the hardware is going to do colour-key compositing then (by default) these requests are meant to do all of the necessary stuff, including filling the target area with the colour-key and telling the hardware where to overlay the video.
Hardly any (I can think of no examples) graphics hardware does this any more. Instead the drivers do something like writing the video frames to textures and then getting the hardware to render them. This leaves the scaled, colour-space-converted video in the real framebuffer, like you'd expect. And it works entirely independently of whether top-level windows are composited or drawn the traditional way. I can tell this, because the window manager I use (e16) lets you turn compositing on and off while it's running, and I've done this in the middle of video playback. (Another simple test is to watch wheher the CPU usage changes when you make the playback window very large or switch to fullscreen.)
[mdw] 12:25, 4 May 2013 (UTC)