Render conformance

Martijn Sipkema msipkema at sipkema-digital.com
Wed Sep 15 07:23:32 PDT 2004


> > [...]
> > Why do we actually use Render instead of just using OpenGL. Another
> > API to learn and implement, not well documented, not cross-platform and
> > hard to accelerate.
> > 
> It is a general model, meaning it provides a standard way to create a
> "rendering library" to an arbitrary devicem like in the Cairo library.

No, it is a rendering API for rendering to a display/framebuffer, just as
OpenGL.

> In this case OpenGL. Standards are good, as long as it doesn't pose a
> threat to efficient use of the underlying mechanism. I think Render is
> well designed to fit most such contexts, that I know of.

I think it is fair to say that OpenGL has been designed with both
the hardware and software in mind and with many participants. This
can not be said for the Render extension.

> The Render
> model has, I think, been proven very efficient when implemented in
> OpenGL, as of the Glitz library.

It appears to be hard to accelerate and does many of the things that
OpenGL does, only slightly different.

> > As for sub-pixel (as in per component) rendered graphics, I think that's a
> > bad idea also. Now pixel data is display dependend and the abstraction of
> > the ``picture element is essentially'' gone.
> > 
> If you don't want it, don't use it :) There are several cases where I
> have seen significant visual improvements from subpixel rendering. I
> know I want it!

Given that it complicates the API, I don't want it. Perhaps if support for
it was added to OpenGL, but I doubt that would be a good idea..

> > [...]
> > - create a single library/API for 2d poscript-like drawing (OpenVG?)
> 
> What, like Cairo?

Yes, something similar. Probably best done in more than one layer, with
a low level library for postscript-like drawing on top of OpenGL/GLU.
This is indeed what cairo/glitz does, but it is IMHO to much implemented
with the Render extension in mind and with OpenGL as an afterthought.

> > - use an auxiliary buffer to render a antialiased path without using
> > multisampling, i.e. make sure most drivers can provide a configuration
> > with an aux buffer.
> 
> Have a look at how Glitz does the davidr-style AA :), when multisample
> is missing. Performance and visual output is impressive. 

I'll have a look, but from what I've seen so far these algorithms, and cairo
in general, allocate memory dynamically. This is not necessary when using
an aux buffer.


--ms





More information about the xorg mailing list