[cairo] Hit detect surface?

[David Trallero Mena]

Carl Worth wrote:
> 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.

Ekko! you hit the nail! ;). I do use CAIRO_ANTIALIAS_NONE, and yes, when
been really close to the drawn object it will not detect the object (if
the original used antialias), so we  can put wider line when stroking or
filling. Anyway... the point is that I need to draw "id-colors", so lets
say that ID is "unsigned int", so how can I pass that unsigned int to 
airo_set_rgba_source? (I do descompose 4 bytes into 3 floats (2
bytes,1,1)).

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

In my layer on top of Cairo I just change the color passed to
"cairo_set_rgba_source" and the context to draw. Something like:

...
context = m_orignal_draw ? m_original_context : m_hit_context ;

redraw_all_scene( context ) ;
...

void redraw_all_scene ( context )
{
    ,,,
    switch ( ... )
	{
             case SET_COLOR:
               color = m_original_draw ? m_orignal_color : m_current_id ;
               ciaro_set_color_rgba( color ) (<- imagine the translation)
	}
}


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

I have to detect in which object the mouse is in every (mouse) motion...
that method will take ages for me ;). Also I do only need screen-pixel
precision.

Using the technique you describe will be hard, as you will have to
consider the alpha value too and make a list of objects (ordered by
depth). Again, although I do not have the algorithm in my mind, I am
sure cairo_in_stroke do consider the transformation matrix, right?

The method (cairo_in_stroke/fill) you describe is _really_ useful for
another kind of applications, and I think it is a really well sensed to
include a function like that in the library.

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

Yeah, whenever you do not rotate your objects it is fine, else a 
rectangle rotated certain degrees can get almost double bounding box :(.

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

Once I had to make a 3D engine like the one in Quake with a good friend
of mine, We got to the conclusion that using and 3D span line algorithm
instead of zbuffer technique was much more more more faster. Even I read
somewhere that it was faster than letting the HD video card to draw the
zbuffer (<- never convince about this, and I am really sure this has
changed hehe). From my point of view, the zbuffer in the actual video
cards could be used in 2D as the hitting buffer :D (the card do draw the
original image and the zbuffer with the same cost), so from this point
of view, it would be nice to include this feature in cairo, the point 
would be: how do you do it for every-surface? I bet video HW surface 
could do it using zbuffer and others would have to use SW implementation 
like the span-buffer line or whatever.

David