Re: 2D antialiased graphics using OpenGL

> > If other than the normal compositing is to be provided then this would
> > still mean rendering to the auxiliary buffer first, since the
fundamental
> > object is not a triangle, but the stroked/filled path. Am I
understanding
> > this correctly?
>
> The fundemental object in cairo is the path; how that is atomically
> applied to the underlying surface is a detail of the specific backend.
> It's possible to compute coverage from the path object itself (that's how
> libart works), but Render uses an intermediate alpha channel to hold the
> data because it's a lot simpler to just draw polygons.

ok, then I understand. In OpenGL rendering to an auxiliary buffer would
be best I think, using smooth polygons. The color values in the auxiliary
buffer will already be multipled by alpha in that case..

> > But how can one do compositing when gamma is not 1? AFAIK graphics
> > hardware expects a framebuffer with a gamma of 1, i.e. a smooth shading
> > will not render gamma corrected in hardware, right?
>
> You would convert from frame buffer values to linear intensity, composite,
> then convert back.  I've heard rumors of hardware that does this, but I
> haven't yet figured out how to integrate this into Render.  So, for now,
> we ignore the distinction and generate inaccurate results.  The worst of
> these is plainly visible when using light text on a dark background.

I haven't tested yet, but doing gradients with the incorrect gamma is
probably even more noticable than the loss in quality from using a gamma
corrected framebuffer.

> > I'd rather have convenient, fast rendering and suffer slightly worse
> > resolution in some color range.
>
> Remember that in 2D graphics land, the number of computed pixels is far
> outweighed by the number of precomputed pixels (from static images), and
> that those images almost universally assume a non-linear gamma.

If they are static, they could be converted to assume linear gamma without
loss of performance (but with a slight loss in quality).

> So, we've
> got the choice of converting the bulk data back to linear values, or
> getting slightly inaccurate anti-aliasing results.

And 3d graphics, gradients... and the difference is quite noticable.

> > If 8 bit per channel is not enough, then the hardware should provide
more.
> > OpenGL rendering clearly expects a gamma == 1 framebuffer I think...
>
> It would be nice to see deeper frame buffers; I made sure that Render
> could describe 16 bit channels, which is probably sufficient, but unlikely
> to become prevalent as hardware vendors move to floating point pixels
> instead of deeper integer valeus.   That will take some modification of
> Render and the core drawing code, but it can be done in a backward
> compatible fashion.
>
> I don't know what GL expects, but I know that I've run it only on gamma >>
> 1 displays...

Fullscreen games often have the option of adjusting gamma and without it
they are rendered incorrectly.

--ms