[cairo] Re: [Mesa3d-dev] OpenGL and Cairo

[Allen Akin]

On Tue, Apr 20, 2004 at 12:57:56PM -0700, Jon Smirl wrote:
| I'll cc this over to the Cairo list. ...

I'm sure they've heard it all before. :-)

|                            ... Any chance one of you OpenGL exports might come
| to Boston? ...

Not me, unfortunately; I've got a deadline April 30th and I won't be
able to come up for air until then.

|                                 ... I'm ok with creating a separate 2D API but
| I'm concerned about how well it maps back into OpenGL. ...

Even more important is how well it maps onto the characteristics of the
hardware.  Possibly as important is where the rendering model is
practically strong or weak.  Compatibility with OpenGL needs to be
considered, but OpenGL extensions can be proposed if there's good
benefit for the cost.

Just an example of how hardware affects API: 3D graphics APIs used to be
path-style (moveto/lineto with fill rules) like Cairo.  The problem with
such an approach is that rendering the filled paths requires a
potentially unbounded amount of memory, nearly random memory access
patterns, and highly variable amounts of time to process each
"primitive."  To be fast, graphics hardware must have small amounts of
fast memory accessed without caching or with extremely predictable cache
behavior, and well-constrained time to process each primitive so that
flow-control is practical in a deeply pipelined implementation.  So 3D
APIs evolved firewalls between high-level constructs (trimmed curves and
surfaces, complex polygons) and low-level constructs (triangles, meshes,
curved patches).  If high rendering performance is a goal, you'd want
similar modularization in Cairo, so that the low-level constructs can be
cached.

And the rendering model:  Even in 2D, an awful lot of stuff is derived
from geometric primitives -- glyphs, scalable drawings/icons, UI
components, etc.  Sticking with geometric representations as late in the
rendering process as possible allows you to take advantage of
sophisticated transformations, accelerated antialiasing, complex
layering, accelerator-mediated effects like lighting, etc.  Going to
image-based representations too early locks you into a fixed sampling
rate (complicating transformation and antialiasing), may increase
storage requirements for intermediate results, limits you to simple
layering and compositing options, etc.  So making the system work well
with geometry at as many stages as possible is very much worthwhile.

Lots more of this sort of thing could be discussed (I haven't even
touched on the architectural issues surrounding programmability, for
example).

|                           ... For example Cairo using a different model for
| drawing gradients ...

Simple gradients on arbitrary primitives fall out of texture mapping,
possibly with automatic texture coordinate creation (texgen in OpenGL).
Arbitrarily complex gradients (and other synthetic fill patterns) fall
out of programmability.  Creating new ways to do this stuff can, in the
long run, lead to a lot of redundancy.

| Did you see these performance numbers for Cairo that were just posted?

Yep.  I wonder if the resulting images are identical (to within the
limits Cairo defines)?

Gotta go -- the deadline is calling.

Allen