Xgl/Xegl future?

[Brian Paul]

Eric Anholt wrote:
> On Wed, 2005-08-24 at 17:49 +0200, Matthias Hopf wrote:
> 
>>On Aug 22, 05 14:56:12 -0400, Michel Dänzer wrote:
>>
>>>On Mon, 2005-08-22 at 19:23 +0200, Matthias Hopf wrote:
>>>
>>>>On Aug 22, 05 01:01:37 -0400, Michel Dänzer wrote:
>>>>
>>>>>On Sun, 2005-08-21 at 21:08 -0400, Owen Taylor wrote:
>>>>>
>>>>>>In order to do a good job with a GL-based compositing manager you need:
>>>>>>
>>>>>> - Redirection of OpenGL and Xvideo clients
>>>>>
>>>>>This is true whether the compositing manager is GL based or not.
>>>>
>>>>But an OpenGL based Xserver can use the graphics hardware for scaling
>>>>and color conversion of XV surfaces (that's what I've been working on).
>>>
>>>So can a GL based compositing manager.
>>
>>No. Not with current Xservers. No way to get YUV / YUY2 data in native
>>format. This isn't easily possible to implement, either, as the PutImage
>>call does not have to completely fill a Window, and RGB data can be
>>drawn over it afterwards as well.
> 
> 
> Obviously a GL compositing manager wouldn't be doing the YUV to RGB
> conversion, since the compositing manager is at the wrong level.  It
> should be done in the XV handler of the driver in the DDX.  It's been
> done in several KAA (aka EXA) drivers before, using the graphics
> hardware for scaling.
> 
> GL isn't needed to do this.

Just FYI, there's the GL_MESA_ycbcr_texture extension that let's you 
pass a YCbCr texture image to GL.  The YCbCr -> RGB conversion is done 
by the hardware when the texture is applied to a polygon.

Arbitrary color-space conversion can also be done with fragment 
programs nowadays.

Using the GL hardware for that kind of stuff seems pretty interesting.

-Brian