Mouse x,y "lags behind" mouse cursor

[sparkbuzz]

The following code in my application is used to move a tiny sphere to the x, y, z picked point on a plane as the mouse moves.

document.addEventListener('mousemove', function (event:MouseEvent) {var pickingInfo:BABYLON.PickingInfo = this.scene.pick(event.x, event.y, function(mesh:BABYLON.AbstractMesh) {        return mesh.name == 'pick_plane';    });    if(pickingInfo.pickedMesh != null) {        sphere.position = pickingInfo.pickedPoint;    }}.bind(this));

The problem I'm noticing is that, even during moderate mouse movement, the sphere's position lags behind the browsers' mouse cursor.

 

I'm assuming that BabylonJS uses requestAnimationFrame() for managing the render loop, and I suppose, because the sphere position is updated in a 'mousemove' event handler, outside of that context, is what's causing the lagging sphere.

 

Perhaps also, because the mouse movement event handler doesn't get called at the same frame rate as the requestAnimationFrame() handler, is what's causing the lag? Would have been awesome if I could get the mouse x, y coordinates on the spot, say for example from the window object.

 

 

Is there a way I can get the sphere to more closely track the position of the mouse cursor?

[iiceman]

Maybe show us in a playground so that we can play around?

[RaananW]

Maybe show us in a playground so that we can play around?

 

That should be a boilerplate automated answer after scanning a new message and seeing there is no link to a playground scene 

 

Regarding your question - the scene has pointerX and pointerY exactly for this reason. no need to access the event's data.

Maybe, if possible (I am not sure about your usecase), try implementing the movement tracking inside the before-render loop (again, only if possible), this way you don't use any external js events (which, as you perfectly said, will be triggered only "between frames".).

[sparkbuzz]

I'll try getting into the habit of creating playground samples. I'm coding in Typescript, so not always certain the code spat out by the tsc compiler will be human readable.

 

Thanks for the pointerX and pointerY pointer, hehe, will incorporate that and see if performance improves.

[sparkbuzz]

 Ok, so a quick test with the pointerX and pointerY gives MUCH better performance...

 

Thanks RaananW!