Still some problems filling non-convex shapes in OpenFL

Haxe
#1

I’ve previously asked about non-convex shapes potentially being filled incorrectly in OpenFL, but I think there’s a new round of problems. Here’s a simple demonstration:

package;

import openfl.display.Sprite;

class Main extends Sprite {
    public function new () {
        super();

        graphics.lineStyle( 2.0 );
        graphics.beginFill( 0x8080ff );
        graphics.moveTo( 100, 100 );
        graphics.lineTo( 150, 100 );
        graphics.lineTo( 150, 150 );
        graphics.lineTo( 200, 150 );
        graphics.lineTo( 200, 100 );
        graphics.lineTo( 250, 100 );
        graphics.lineTo( 250, 150 );
        graphics.lineTo( 250, 200 );
        graphics.lineTo( 200, 200 );
        graphics.lineTo( 150, 200 );
        graphics.lineTo( 100, 200 );
        graphics.lineTo( 100, 150 );
        graphics.endFill();
    }
}

It’s clear that the boundary of the U-shaped pentomino doesn’t match up with the region that ends up getting filled. This is with OpenFL 2.2.6 testing with neko, though I see the same problem with other targets too.

The problem might be related to collinear vertices – at least, the problem goes away in this example if I eliminate the collinear vertices.

(Forgive me for not filing a bug against this behaviour. Because of the scope of OpenFL and Lime, I’m honestly no longer sure where specifically to file the bug report. If someone would like to educate me on that front, I’d be happy to try to take that route in the future.)

Thanks.

#2

If it works in Flash but doesn’t work on other targets, file a bug report.

That said, I can’t reproduce the issue. I’m still using an old version of OpenFL, but presumably that wouldn’t make the difference.

Edit: turns out, it did make a difference. It worked in 2.2.3, but now it does this:

#3

Yes, that’s the behaviour I’m seeing. Thanks for checking. So, where do I file the bug report? On github against the main OpenFL project? Or is this a Lime thing?