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.
Attachment:
pgpMgqRbnfMYz.pgp
Description: PGP signature