[Gnash-dev] Re: point test

[Sandro Santilli]

Background: we need shape topology construction for both rendering
            and hit test functionality (point_test).

On Sun, Nov 04, 2007 at 01:03:09AM +0100, Bastiaan Jacques wrote:
> I've been thinking about the point_test issue some more. In my opinion,
> point testing should be done by the renderer, because...
> 
> a) The renderer must know about fully qualified shapes and fill styles
> anyway, in order to render anything.
> b) Each renderer library we currently use has a method just for this
> purpose (Agg: hit_test(), Cairo:  cairo_in_fill(), OpenGL: selection
> mode).
> c) If we let the renderer deal with point_test, we avoid duplicating the
> effort in the Gnash core.
> 
> Of course we would need to design a nice interface. We might also
> implement a caching mechanism. All this will make Gnash faster than it
> currently is.
> 
> What do you think?

Seems an easy path, we may try that as a start.
Doing so shouldn't preclude future changes.
We do already have a caching architecture (where caches are bitmaps)
so adding normalized topology to the caches shouldn't be too hard.

The interface should be simple:

 /// No matrix transformation reqired, coordinates in local twips.
 /// The Point2d might be parametrized with floats instead of int (as the cache 
might
 /// be more convenient in floats for faster transformations on ::display)
 bool render_handler::hitTest(const shape_character_def& shape, const 
Point2d<int>& queryPoint) const;

The renderer will need a way to tell wheter the cache was invalidated.
This is particulary important for DynamicShape, when actionscript can modify 
the paths
(clear or add new paths). DynamicShape already has a "dirty" flag, and a 
::finalize method
designed for normalization (just not implemented).

Note that taking care of normalization in the core lib would reduce memory 
usage (ie: the core
lib won't need to keep both the normalized and source representations) and 
leverage eventual
differences/bugs in the renderers. But could be eventually a separate step.

--strk;