[cairo] Cairo vs. Canvas

[Carl Worth]

On Sun, 12 Sep 2004 18:41:13 +0100, Andrew Birkett wrote:
> I am excited by the idea of a high-quality cross-platform drawing
> package, but I'd like to ask if cairo is intended purely as a drawing
> library, or if there will also be support to allow interactive
> applications to discover which drawing primitives are at/near a
> particular point (eg. under the mouse cursor hotspot)?

I think that cairo's focus is to be a drawing library. That said, a
useful drawing library has to be able to let the user ask about how
some things were drawn. But I don't think that cairo necessarily needs
to provide every analytical geometric operation that an application
might want to perform.

> I have looked in the archives and found some early discussion of this
> topic, eg. 
> http://cairographics.org/pipermail/cairo/2003-October/000607.html.  Has
> there been any concrete decisions made on this since?

Yes. Shortly after the discussion you quoted, (on 2003-11-06), we
added the following two functions:

	cairo_in_stroke
	cairo_in_fill

which return a boolean indication of whether the provided user-space
point is within the shape that would be be drawn by cairo_stroke or
cairo_fill respectively. The implementation uses geometrical
containment within fixed-point device space coordinates, (eg. not
rounded to the device-space grid).

A little over a month later, (2003-12-16), we added cairo_text_path
which enables the user to make similar containment queries about glyph
shapes, (as was requested in the thread above).

> So cairo would have to allow the app to ask questions about what painted,
> otherwise the app would be duplicating and second-guessing what cairo
> had already done.

Yes, the second-guessing should be avoided. And I think we've got most
everything in place for that now. (Actually, cairo_stroke_path is
still missing so that the application can query the geometry of a
stroked path's perimeter, but that function is planned).

> I have two other related points which might be relevant.  Firstly,
> point-in-path isn't enough to answer "which paths are within 5 (units)
> of this point" which is required to allow users to select thin one-pixel
> thick wires without have to exactly position the mouse over it.  Also,
> if there are multiple paths nearby, it would be useful to find the
> distance to the nearest point on each. Secondly, marquee-select (eg.
> dragging out a dotted rectangle to select multiple items) requires the
> app to find out which paths intersect with the rectangle.  I guess
> accurately supporting lasso-like selections is even harder, since that's
> an arbitary path/path intersection.

I think most of these other analytical operations fall outside the
scope of cairo. At some point, the application provides the geometry
to cairo, so it has the information to do analytical operations on it.
cairo_stroke_path operation to enable that.

Arbitrary path/path intersection would be a nice operation to have in
many cases, but it's not trivial to implement. We don't need it (yet)
inside of cairo, but if we do end up implementing it, we will export
it so that applications can share a robust implementation.

-Carl

PS. I'm sorry for the very tardy reply. But one nice thing about
looking at this message today is that it pointed out that old
pipermail URLs have been broken since the server compromise. I've put
in a fix for that now.