[cairo] Hit detect surface?

[Carl Worth]

On Wed, 01 Mar 2006 11:27:38 +0100, David Trallero Mena wrote:
>
> render everything again there. This new surface I use I refer to as 
> select surface (hit-surface for you). The color used when re-rendering 
> is indeed and ID (I have to talk with cairo guys about this) of the 
> figure (rectangle, ellipse, circle...) that was rendered on the 
> "original-surface".

You found us cairo guys. What questions do you have?

As for this technique. To use it, one would want to ensure that no
colors appeared in the output other than the "id" colors. It's
possible to get that with cairo by using CAIRO_ANTIALIAS_NONE. But, we
don't currently make any strong guarantees about the precise behavior
of ANTIALIAS_NONE rendering. So the results might differ by a pixel
here or there from what you would might prefer.

> Taking external events like mouse or joystick-motion or whatever I just 
> have to read in the "hit-surface" and see the ID to know which element 
> was drawn on that point. In my case the ID means the widgets drawn 
> there, in yours, it can means the structure that contains the figure 
> with the operators and colors used,

I think what Bill was trying to get at is a mechanism to define the
shapes entirely by the code that uses cairo to render them. Your
approach requires a slight modification to the rendering code, (using
ID values instead of the colors desired).

And the tradeoff there is between how invasive the approaches are to
cairo's implementation itself.

And as we're talking about picking, there are other techniques that
should at least be mentioned. Cairo can determine whether a given
point is within a path as stroked or filled with cairo_in_stroke and
cairo_in_fill. This is much more precise than anything pixel-oriented
such as ANTIALIAS_NONE rendering and examining a pixel.

In one sense, cairo_in_stroke/fill is the fundamental operation
needed. It's just not very cheap, (each call does all the tessellation
of cairo_stroke/fill, but not any rasterization or compositing). So
the question just becomes how to optimize the code around this. The
ANTIALIAS_NONE rendering with ID colors is a way to get a
low-resolution cache of these calls for a set of of priority-encoded
shapes.

Other techniques for optimizing picking might rely on geometric
descriptions of the objects. Bounding boxes would be the simplest such
description, but one could get much more elaborate than that for
better optimization.

The obvious disadvantage of such an approach is having to maintain
geometric descriptions separate from the rendering code. But an
advantage is that ambiguous picks could easily be detected and drop
down to the precision of cairo_in_stroke/cairo_in_fill as needed.

Which combination of techniques is best depends a lot on the needs of
the application and the data it has available.

-Carl

PS. When I cross-posted thread like this lands in my inbox, I'll send
a single cross-posted reply like this one. After this, be prepared to
chase down replies to individual lists if you really care about how I
might reply.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060301/b3e0b268/attachment.pgp