Re[2]: [Gnash-dev] Problem with Drawing API

[Udo Giacomozzi]

Hello Sandro,

Wednesday, November 7, 2007, 8:49:21 AM, you wrote:
SS> Another *important* thing to verify is the DrawingApiTest.swf
SS> with the proprietary player.
SS> In particular the 4 versions of the nested squares (with green
SS> fill).

The only square with a green fill I see is the one that was there
already before your patches, ie. the one between the cyan and magenta
square.


SS> Those tests seem to show that "normalization" happens whenever
SS> a fill is closed and a new one is added, with pen movements
SS> not automatically closing the fill.

It is possible that the p.p. renders dynamic shapes with a different
implementation, that is with a normal rasterizer that uses only one
fill side (the classic one). Rendering those shapes with a normal
even-odd filling rasterizer would solve all these problems because it
eliminates the problem with
- intersecting edges
- fill style sides
and there is no need for normalization.

However I currently see no way to find out what the folks at
Macromedia have really done...


SS> I'm saying this because the first two squares seems to be 
SS> rendered with an hole, and the subsequent two withouht.
SS> The only difference between the with-hole and without-hole
SS> versions is an additional call to beginFill, specifying the same
SS> fill already in effect.

If the above possibility is correct and they use a different
rasterizer for dynamic shapes the AS calls would have these effects:

- beginFill starts a new sub-shape (m_new_shape is set) and path
- moveTo starts a new path


There is a special test that gives indication that the p.p. maybe
really uses a different rasterizer:


-------------------------------------
test.beginFill(0xFF0000);
test.moveTo(100, 100);  // 0
test.lineTo(200, 100);  // 1
test.lineTo(200, 200);  // 2
test.lineTo(100, 200);  // 3
test.lineTo(100, 100);  // 4

test.lineTo(50, 100);   // 5
test.lineTo(50, 150);   // 6
test.lineTo(150, 150);  // 7
test.lineTo(150, 180);  // 8
test.lineTo(100, 180);  // 9

test.endFill();
-------------------------------------


  5-----0-----------1
  |#####|###########|
  |#####|###########|
  6-----+----7######|
        |    |######|
        |    |######|
        9----8######|
        |###########|
        3-----------2

Point 0 is equal to point 4 and the implicit last point.


The p.p. renders a continuous shape but the AGG renderer breaks the
shape between point 9 and 0, i.e. there is a red line between 9 and
the crossing and a white line from there to point 0.

This (the AGG result) could be a side effect of the two overlapping
edges (which have the same direction and fill style!). It is possible
that the p.p. renders this differently because it does not use the
compound rasterizer for the dynamic shape.

It's possible that this is a false assumption, though.

Can you resemble the test in Ming, producing a malformed SWF? This
could clarify some things...



Udo