IsPointerBlocker Improvement

It appears that the GUI.Control.isPointerBlocker flag only allows one to stop pointer events from propagating through the scene. I’m curious why this doesn’t also stop the pointer events from propagating up the GUI control hierarchy. Perhaps even better would be another flag that separately controlled this (e.g., GUI.Control.isPointerGUIBlocker).

I’ve also noticed some other odd behavior with this flag. E.g., if I have code that “drag” animates a control with the mouse pointer, and which disables the scene’s pointer events via isPointerBlocker, I get a very noticeable slowdown in performance. (If anything, wouldn’t one expect an improvement in performance here?)

Additionally, I said “propagating up the control hierarchy” because that is indeed what seems to be happening. Mouse events activated by a control seemed to get passed on to its ancestors - regardless of their positions. (I.e., the “parent” control will receive the mouse event triggered by its child even when the mouse pointer isn’t actually positioned within the parent.) You can see that here: . This doesn’t really seem optimal.

If I got anything wrong here (or I am simply missing the reasons for the current design) I would be grateful for the correction. If not, perhaps this behavior could be improved?

cc @RaananW, @carolhmj and @DarraghBurke :wink:

Hey, I just wanted to check, do you have an example of this happening?

It happens very clearly in my codebase when I do nothing but set/unset that flag. To re-create this entire system in your playground would probably take me a day or two. I thought if I described the problem precisely, whomever wrote the “isPointerBlocker” logic might have enough insight to figure out why this occurs.

You wouldn’t need to recreate the entire system, just enough for it to happen :slight_smile:

Of course, that’s what I meant.

And think about it: regardless of what my (or anyone’s) code is doing, can you think of any reason why setting a flag that supposedly disables mouse pointer logic in the scene would ever decrease performance? My point is, it shouldn’t matter what code I am using, and nothing that I write should cause it to happen! :smiley:

I agree that it shouldn’t be happening, it’s just that having a reproducible set up would make finding the root cause easier :sweat_smile:

1 Like

PR up now with the events not going up the hierarchy if the control is a isPointerBlocker: isPointerBlocker fixes by carolhmj · Pull Request #12787 · BabylonJS/Babylon.js ( :slight_smile:


The new PR change appears to break existing behavior for scenes utilizing a Video and Photo Domes. Likely resulting from the fact the mesh covers the scene and captures inputs. So it may exist in other similar scenarios. See behavior. See PG: and

Click and drag from outside of GUI element to gain control of camera. Release mouse from within the GUI element. You’ll notice the camera is still observing the mouse movement and pans around with mouse even though click/pointer has been released.

If it helps, I created a PR on a fork just to highlight a fix that worked for my particular case. This allows the release (POINTER_UP) to propagate up to the scene so the camera can remove its observer. Fix Drag/Release Behavior in GUI and Photo Dome by stevendelapena · Pull Request #1 · stevendelapena/Babylon.js · GitHub

1 Like

The fix makes sense to me, would you like to contribute it to the main project? :smiley:


Sure - will do.