Re: [Gnash-commit] gnash ChangeLog server/parser/shape_character_d...

[Udo Giacomozzi]

Hello Udo,

Monday, November 12, 2007, 8:24:29 PM, you wrote:
UG> Log message:
UG>         * server/parser/shape_character_def.cpp: point_test_local bugfix:
UG>           revert last commit and align test coordinate to a grid instead;
UG>           commit some debug so I don't have to rewrite it again... ;)

A few words on this commit:

Lots of problems come from junction points between two edges when the
test point has *exactly* the same Y coordinate as the junction. For
example, see this situation:


          1     T
         / \
        /   \
       /     \
      /       \
     /         \
    0-----------2


The test point "T" and the anchor 1 have exactly the same Y
coordinate. The point_test algorithm would find that lines 0-1 and 1-2
cross the scan line and would first increment and then decrement the
counter resulting in a zero final value, which is correct.

Now see this situation:

              2
            /  \
          /     \
        1        \   T
       /          \
      /            \
     /              \
    0----------------3

The algorithm now finds three crossings:
 1) line 0-1: increment counter (upward)
 2) line 1-2: increment counter (upward)
 3) line 2-3: decrement counter (downward)

This results into a final value=1 and so it thinks that "T" is inside
the shape! The problem is that the point "1" has been counted twice
even if both sides go into the same direction.

This could be addressed by checking the directions but this becomes
problematic when the *path* anchor point itself is the problematic
one. To make it even more complicated: a signle path does not have be
closed, so junctions cannot be detected easily.


Since this becomes too complicated I decided to go for an easy
solution: All coordinates of the definition are aligned to the TWIPS
grid, which is an advantage because so I can shift the test point to
some coordinate off the grid and so I avoid completely the
scanline-on-junction situation. It will *never* happen that the
modified "T" position is on the same Y coordinate of any edge.

The downside of this is that I'm limiting the point_test accuracy. But
the current design should not reveal any inaccuracy unless you do
_xscale = 4000;


One problem remains with dynamic shapes (again), which are not forced
to the TWIPS grid. I suggest we align coordinates of dynamic shape
definitions too (ie. *store* them aligned), so we avoid this problem.

I think that's exactly what the proprietary player does, since the
following code shows inaccuracy after about 40 frames, while it should
not make any difference from a pure mathematic point of view:


//////////////////////////////////////////////////////////////////

mag=1;
this.onEnterFrame = function() {

        this.createEmptyMovieClip("bla", 10);
        
        bla._x = Stage.width/2;
        bla._y = Stage.height/2;
        
        var i;
        
        bla.lineStyle(0,0xFF0000);
        bla.moveTo(0,0);
        
        for (i=-100; i<100; i++) {
                bla.lineTo(i/mag, Math.sin(i/10)*100/mag);
        }
        
        bla._xscale = mag*100;
        bla._yscale = mag*100;
                
        mag++;

}

//////////////////////////////////////////////////////////////////

Udo