[cairo] Re: [Mesa3d-dev] Points in Cairo Glitz paper

[Carl Worth]

On Thu, 22 Apr 2004 18:38:43 +0200, David Reveman wrote:
> On Thu, 2004-04-22 at 08:41 -0700, Jon Smirl wrote:
> > But this is getting to my core point. Do we want offscreen rendering to be
> > important to Cairo, or should we redesign Cairo to not need it?
> 
> Maybe I was I bit off when I said that without
> cairo_surface_create_similar we can't do much. We've actually taken a
> big step in the direction that you're describe with the introduction of
> the new pattern interface to cairo. The OpenGL backend now much more
> rarely need to use offscreen surfaces. e.g. solid stroking and filling
> was done using offscreen surfaces earlier but that's no longer
> necessary. Same thing with gradients, before we had the pattern
> interface the only way to do gradients, was to scale an offscreen
> surface. 

David, this is encouraging to hear.

One thing that might help the discussion is a more grounded
understanding of the API exported by cairo. I haven't yet tried to draw
any sort of pipeline for cairo, but maybe a bit of prose will suffice
for now.

First, a few definitions:

Pattern: Currently a solid color, linear gradient, radial gradient, or a
bitmapped image. In the future, I would hope the pattern could be a more
general, programmatic object.

Path: A set of one or more simple paths.

Simple path: An ordered list of linear and cubic Bezier segments. May be
closed or open.

Line style: join type (miter, round, bevel), cap type (butt, round,
square)

With that, the most complex cairo operation is conceptually something
like the following. The description below ignores details such as
several possible transformations and doesn't carefully describe
semantics of things like "within region" and the impact on pixelization.
But hopefully it will be useful for the current discussion anyway.

Stroke: Accepts as input a pattern, a path, and a clipping path.
Computes the region formed by stroking the path with a circular pen
according to the current line style. Intersects that region with the
region inside the clipping path. Fills the resulting region with the
pattern and composites that onto the destination according to a
specified Porter/Duff operator.

I don't think we have graphics hardware today that can tackle that
complete operation, (if someone does, please send it to me), but this is
the basic operation that makes cairo what it is. So, obviously there
will be software inside the cairo implementation, (eg. the spline
stroking algorithm). The interface between that software and the
underlying graphics system (eg. OpenGL) is flexible, and I'll be glad to
adjust it as necessary to accommodate the underlying implementation.

For example, the current implementation implements clipping in a rather
braindead way by rasterizing the clipping path and using the resulting
image as a mask within the backend. We're fixing this by switching to
passing the clip region to the backend as a list of geometric primitives
(ie. trapezoids) in the same way that the stroked path region is already
passed. This change has no affect on the cairo API.

Does anyone see anything horribly bad about trying to implement
accelerated rendering for the operation described above?

-Carl