Mouse events now being received by entire bounding box of paths?

Haxe
#1

In old versions of OpenFL, when I drew a bunch of paths in a Sprite and then set that Sprite to receive mouse events, the events were received when the mouse was clicked in a part of the path that I had actually drawn. In the newest version of OpenFL, it seems as if mouseEvents are received by a sprite if you click anywhere within the axis-aligned bounding box of the paths that are drawn. Is that the intended new behaviour, or am I missing something obvious?

The following program will demonstrate the difference.

package;

import openfl.display.Sprite;
import openfl.text.Font;
import openfl.text.TextField;
import openfl.text.TextFormat;

import openfl.events.MouseEvent;

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

        var sub = new Sprite();
        sub.graphics.beginFill( 0x000000, 0.5 );
        sub.graphics.drawCircle( 300, 100, 40 );
        sub.graphics.drawCircle( 100, 300, 40 );
        sub.graphics.drawCircle( 500, 300, 40 );
        sub.graphics.drawCircle( 300, 500, 40 );
        addChild( sub );

        sub.addEventListener( MouseEvent.MOUSE_DOWN, mouseDown );
    }

    private function mouseDown( event : MouseEvent ) : Void
    {
        trace( "mouseDown" );
    }
}

When I run lime test neko and click anywhere in the bounding box of the four circles, I get the mouseDown message. When I run lime test neko -Dhybrid or lime test neko -Dlegacy, I only get events if I click within the actual circles.

Advice welcome, thanks.

Feeling stuck -- problems with new and old versions of OpenFL. Advice?
#2

In the legacy renderer, it performs a pass through the renderer in order to determine hits. In the newer code, it tries to use only object bounds in order to perform faster hit detection – but you’re right, this doesn’t help with primitive graphics and the equivalent of the shapeFlag boolean. Perhaps (now that we’re using Cairo) there’s some fast way to check

#3

OK, that explains it, thanks. Yes, in the future it will be helpful to retain a way to check for hits on primitive geometry, or to specify proxy geometry to use for hit testing (which I believe is also possible in legacy).

In a way, what surprises me the most is that so few users seem to run up against these geometric issues (another low-level problem: I think some non-convex polygons still aren’t triangulating correctly). I deduce that I’m in a small minority of people working with pure, procedurally generated geometry. Most people are working with image-based sprites and simple grids of tiles, I suppose?

More comments in our other thread.

#4

Using simpler geometry generally has better performance. I’m curious, though, you said you might not have had accurate rendering with the newer code, do you have an example? In my tests it’s much more accurate

#5

I tried to concoct a simple test just now with a bunch of polygons. It seems as if the newest code has indeed stabilized — I’m not getting any polygons rendered incorrectly in lime test neko. I still see problems with lime test neko -Dlegacy, but I assume that’s not going to updated, right? Because I’m stuck with legacy for now, I’ve written my own quick polygon triangulator. It’s a bit slow, but my polygons basically don’t change so I only need to triangulate once. (In fact, I’ll probably write a separate preprocessor and bake the triangulations into the source code, in which case this won’t matter for now.) Thanks for getting everything working in the new code; I look forward to migrating to it later.

#6

You’re right, the renderer in legacy is not going to be updated. The goal for legacy is to remain stable, while we try to push the new code to maturity as quickly as possible.

Thanks again for your help and support :slight_smile: