[cairo] New OpenGL backend merged

[flying.toaster]

Maybe I am missing a point (since I have been  off for quite a while) but at application level, you can force full screen anti-aliasing, rather than primitive drawing anti-
aliasing, using the accumulation buffer and sub-pixel jitter (changing the viewport) in OpenGL to an arbitrary accuracy. Sure it is a GPU hog, but then again, I bet a very 
complex SVG drawing is not that complex to draw compared to any common 3D scene found in a recent video game, where FSAA is often used with good frame rates. 
Text rendering may be another story though...

Just my two cents

Enrique

> Message du 23/07/09 à 11h20
> De : "John C. Turnbull" <ozemale at ozemail.com.au>
> A : cairo at cairographics.org
> Copie à : 
> Objet : Re: [cairo] New OpenGL backend merged
> 
> 
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > Sent: Thursday, 23 July 2009 19:00
> > To: John C. Turnbull
> > Cc: Cairo list
> > Subject: Re: [cairo] New OpenGL backend merged
> > 
> > A backend for Cairo provides a means of rendering through the Cairo API
> > to a particular architecture. For example, to render to a PDF file, you
> > create a PDF surface which uses the PDF backend. Similarly for the
> > other
> > vector file formats. For raster devices, i.e. your display or a pixel
> > buffer, everything is slightly more complicated due to the varied
> > hardware architectures and desire to interoperate with the various
> > libraries. The 'simplest' raster backend is the image backend which
> > uses
> > pixman as a software compositor. Then we have the native backends such
> > as win32, quartz and xlib, which use the native windowing system to
> > provide acceleration wherever possible and we fallback to pixman when
> > not. More often than we would like, we have to fallback to pixman (or
> > in
> > the case of xlib, the server has to fallback to pixman and is unable to
> > accelerate our request).
> > 
> > The promise of a direct rendering interface like OpenGL or DRM is that
> > we can issue commands to the GPU independent of the native windowing
> > system. This means we can completely bypass the partial support for
> > Cairo exposed through the native 2D API and implement acceleration for
> > any layer of Cairo - for example, offloading of high-quality
> > tessellation onto the GPU is a long desired goal. In the short term, it
> > means that we can actually provide h/w accelerated sampler (images,
> > gradients - as already demonstrated by glitz) and use the more
> > efficient
> > rasterisation techniques that have not yet been propagated through
> > RENDER to the xorg drivers.
> > 
> > The other aspect of the OpenGL backend is that it will allow more
> > convenient interoperation of Cairo with OpenGL programs. Currently you
> > have to render to an image buffer and use that as a texture if you want
> > to take advantage of the Cairo inside you GL application. With the
> > image
> > backend, you should be able to use cairo-gl to render directly using
> > the
> > GPU into textures (or straight on to the framebuffer).
> > 
> > I hope that helps to clarify a few concepts. Keep having fun using
> > Cairo!
> 
> Thanks very much for that Chris - it has helped me a lot.
> 
> One thing I have noticed about OpenGL is that it seems to be difficult to
> achieve good antialiasing because this appears to be under the control of
> the graphics driver and therefore the end user can turn it on or off.  Does
> using an OpenGL back-end for Cairo mean that it will also suffer from this
> problem?  Or is there a way to force antialiasing on at all times when using
> OpenGL?
> 
> Thanks,
> 
> -JCT
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
> 
> 

____________________________________________________

Le week-end sera pluvieux ? Quel dommage !... Mais pas de panique le nouveau Guide TV de Voila est là  http://tv.voila.fr