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

[Carl Worth]

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

And I'll CC back just to let anyone interested know that the thread has
been picked up. But, I think the continuation of this thread is most
likely off-topic for mesa3d-dev, so I'd be fine if replies were directed
just to the cairo list.

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

Not necessarily. Cairo isn't finished yet, and until it is, I'm always
happy to hear good ideas --- especially from people who understand
underlying systems better than I do.

And as we talk about cairo, the only part that is (or will be) set in
stone is the public API. We are free to continually change the details
of how it interacts with the underlying graphics system.

I don't want to freeze the API until we have good support for everything
in each backend. This is one reason I'm anxious to get the PDF backend
going -- to make sure there aren't any hidden problems in the
API. Today, we've got PostScript-like, path-based drawing fairly well
supported for user-visible image buffers, Xlib drawables (with or without
Render), and OpenGL.

We very recently added support for linear and radial gradients, and the
API for that was provided along with an OpenGL implementation by David
Reveman.

Things I would still like to see added to cairo include filters and
programmatic patterns, (ie. programmable with cairo calls). For these
new things, I would be very interested in input from people with
experience with OpenGL and other potential backends.

> 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.

That all sounds perfectly reasonable to me. Cairo's path-based API was
designed to appeal to application programmers. If we were wrong in that
choice, then cairo will be ignored and none of this discussion will
matter. If we were right, then the only question is how to make a
high-performance implementation. I don't see anything in your paragraph
above that suggests this should be impossible.

The current implementation seems to fit your description. Cairo accepts
high-level constructs (paths) and emits low-level primitives (lists of
trapezoids). And we've got an OpenGL backend that seems to handle this
quite well.

> 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.

This also sounds quite reasonable to me. I am not aware of anything in
the cairo API that requires premature rasterization. But I would
obviously like to hear about it if someone sees something.

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

I'm certainly interested in continuing the discussion.

> 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.

Like I said, we've been letting people doing actual backend
implementations push up the API specifications to us. Most of the recent
additions have been provided by those implementing the OpenGL backend,
so I don't think we're inventing much redundant there.

-Carl