Re[3]: [Gnash-dev] Re: point test

[Udo Giacomozzi]

UG> I'll try to implement my algorithm soon so we can check if it is
UG> valid (at least it will be a fallback if we decide to go the
UG> renderer way). 

Ok, I've done the implementation. It works with lines and curves. As
far as I can tell it works fine with all files.

I'm currently running "make check"...

To test the new implementation, you have to uncomment this macro in
shape_character_def.cpp:

  #define USE_NEW_POINT_TEST

The problem with this implementation is that it ignores outlines which
should be included in the point test. The older implementation takes
care of this with a distance algorithm, which could be simply pasted
to the new implementation I think.

However, in the long term this won't be a good solution because there
are several kinds of line joins and line caps.

I see these possibilities (maybe implemented later):

- we simply add special code to the point_test algorithm that deal
  with lines, i.e. add additional code for other joins/caps

- we go the renderer-way (let the renderer do the test), [still don't
  like this]

- we implement stroke-to-shape conversion in the core. This has the
  advantage that all renderers will render strokes the same way and
  correctly. Neither the point_test algorithm nor the renderers would
  have to deal with strokes anymore. Also, they can be computed at
  parse time instead continously at runtime (= performance gain too).
  So strokes would become simply shapes. The disadvantage is that we
  have to implement the conversion ourselves and probably do major
  changes in all renderers (mostly removing code).

Note that AGG for example does this on the fly: it takes the outlines
and converts them to shapes, even hairlines since there is no such
thing like a "line" in the renderer world (everything needs to have a
size).

Suggestion: We extend my new point_test implementation with Sandro's
outline check (distance check) and ignore join/cap styles for the
moment. Result: A working point_test without regression.

Later we can plan the step to avoid handling of outlines in the
renderers. I especially like that outlines get converted at parse time
which would probably mean a notable performance gain for AGG. Don't
know how much it would affect OpenGL since maybe it would just remove
some load from the hardware.

The only problem with this solution is that outlines aren't flexible
anymore (a outline is never smaller than a hairline when scaled down
which means it grows compared to it's definition).

Udo