[compiz] Using glitz directly vs using XRender

[David Reveman]

On Wed, 2006-04-12 at 23:08 +0100, Mike Hearn wrote:
> > Looks correct. I highly recommend using xrender. Any filter support
> > being added to cairo should be able to use the existing filter interface
> > that is part of xrender and already accelerated by Xgl. Using glitz
> > backend shouldn't give you anything extra. Using it will just add some
> > overhead from creating an additional GL context instead of having Xgl
> > use its core GL context.
> 
> Huh. So does that mean the XRender protocol will be extended as time 
> goes by to simply have whatever effects are added to Cairo? What if my 
> app wants to do something like draw some shapes with Cairo then do a 
> hardware blur ... with GL I'd use a pixel shader, but how is that 
> expressed in XRender? It knows about each effect individually?

It can be done using a convolution filter. Like the dynamic shadow patch
I sent to the list a few days ago. Eventually, we'll add better filter
support to cairo and then you can just use that, which should be
simpler.

> 
> I dunno ... it just seems odd to have two protocols to talk to the 
> graphics hardware, GLX and XRender, when GLX presumably has so many more 
> features. I know I've seen debate on the xorg lists before on whether 
> incrementally extending XRender is a good idea or whether it'd just turn 
> into a GL clone eventually.
> 
> What are your thoughts on that?

You have a lot of clients connected to the X server and drawing 2D
graphics, 50 or 100 clients is not uncommon. Having each of these
clients create a GL context for rendering is not a very good idea. They
definitely don't need a whole GL context to do what they want, they just
need a small subset. Xrender is such a subset and it's exactly what most
applications need. Xrender can also be more efficient than GLX as state
can be shared much more easily between multiple clients. E.g. glyph
cache or a pixel shader for convolution filtering can be used by more
than one client...

-David