Xgl server

[c99drn at cs.umu.se]

Quoting Jon Smirl <jonsmirl at gmail.com>:

> On Sun,  7 Nov 2004 22:32:17 +0100, c99drn at cs.umu.se <c99drn at cs.umu.se>
> wrote:
> > Quoting Jon Smirl <jonsmirl at gmail.com>:
> > 
> > > On Fri, 05 Nov 2004 12:24:08 -0500, Jim Gettys <jim.gettys at hp.com>
> wrote:
> > > > This is absolutely, stupendously wonderful!
> > >
> > > Dave, how much faster would you say XGL is than the current X server?
> > > Have any simple benchmarks from the parts of the system that work?
> > > Even without benchmarks, how much faster does it feel, is the
> > > difference obvious to a normal user?
> > 
> > That's very hard to say. I don't know how well OpenGL's line drawing and
> bit
> > blitting compares to a well accelerated XOrg driver, but I dought it's
> faster.
> > However, if it's slower, I don't think it's so much slower that there's a
> > problem.
> > 
> > It's important to know that glitz and XGL are designed to be fast at
> RENDER. So
> > applications that use RENDER, like a composite manager or a cairo
> application,
> 
> Won't Cairo applications use glitz when DRI is available? Has an API
> been sorted out yet to automatically switch between glitz and xlib
> backends when DRI is there? Cairo/glitz on DRI will direct reader
> bypassing XGL so it's drawing speed won't matter.
> 

Yes, they could. But so far my intentions with cairo's glitz backend have been
that it would provide cairo output for applications that favor performance over
quality, e.g. no anti-aliasing or hardware multi-sampling for anti-aliasing,
double buffered visuals and buffer swapping for all-animated-redraw-everything
like applications, and possibly also in the future really high performance
retained-mode rendering.

Most applications still fall in the category of applications that favor quality
over performance, and right now, I'd rather see them using xrender. Xgl will be
able to provide maximum performance without loss of quality for these
applications. If direct rendering turns out to be significantly faster than
xrender->xgl rendering, (which I highly dough for this category of
applications) then switching to glitz instead of xrender when DRI is available,
might be interesting, although I'm not certain that we need an additional API
for that. Applications need to provide backend specific options, and the
current way to do that isn't bad.

Cairo's glitz backend can't provide the same quality as the xlib/xcb backends
right now, but that should be made possible in the future, and it's of course
required if we'd like applications to switch to glitz when DRI is available.

-David