Today I noticed (on my Mac) that when I am moving the mouse around, the FPS drop to around ~5 while the scene is calm and nothing is happening.
Is there something Babylon is doing on every mouse move, like trying to pick for meshes? I disabled all of my mouseMoves, and I am not doing any picking except for rays. It happens also when the pointer is locked.
I didn’t notice it on my game PC because the drop isn’t really there but I sometimes see a few fps drops when rotating around, but on my Mac as you can see, the drops are massive.
Even the video itself is lagging, maybe I can get a video on my phone and upload it to see it better.
Yep, bjs will cast rays to all meshes with ActionManagers for instance
I am not using ActionManager, is there anything else?
any object with isPickable turned on?
can you share a repro maybe?
Each of my rooms is a merged mesh of around 200-300 meshes, the merged mesh has isPickable set, but also all of it’s submeshes have it se to true (i suppose because of bounding boxes).
Is there a way to ignore the picking on mouse movement? I’ve read a thread on it some time ago but forgot what was needed to be done.
Added
this.scene.pointerMovePredicate = () => false;
this.scene.pointerDownPredicate = () => false;
this.scene.pointerUpPredicate = () => false;
But nothing has changed.
All of the meshes have to be run through this function that just returns false anyway, so maybe I could PR a change that could disable these pointer checks?
I am not sure if this would fix my issue tho.
So it’s not just my game - I updated your demo - https://www.babylonjs-playground.com/#6LDNAE#6
If you move your mouse really quickly the fps drops to 6.
I set the pointerMovePredicate = function (mesh) { return false }
Btw this is on 2015 macbook pro retina, so you might not see the fps drops, but I see 60 to 6 really quickly.
Update: setting pointerMovePredicate = null did not help either
This is because we were manually doing a pick
here is the version with no pointer pick on move: https://www.babylonjs-playground.com/#6LDNAE#7
Still the same, no change 60 to 10 fps in a few mouse moves. I gotta shower, will upload a vid in a min.
this is the profile I just did:
You can see that the pointermove is insignificant
Ok, let me do a profile on the mac.
Holy shit 
I just figured it out.
I changed the polling of my Logitech g604 connected through LIGHTSPEED from 1000 to 125 and the issue is gone…
A wireless mouse totally knocks off WebGL because of the high polling rate.
Although using the trackpad also takes off good 10-20 fps so I think there is maybe still something going on.
3 Likes
A 17 fps frame using the trackpad, lots of idle time.
definitely a system or driver issue
We can see that the JS code is remarkably quiet 
1 Like
Yeah I suppose it’s a mac or chrome for mac system/driver issue.
I’ve read somewhere that the chrome for mac has WebGL issues.
1 Like
I was Googling around to try to figure out why my game totally freezes when the mouse moves, even when I remove everything linked to capture mouse movement from the code.
Your post made me realize it’s the same for me, no problem with my trackpad and only with my gaming mouse (G502, wired). I dropped the report rate from 1000 to 125 and it’s all good.
Thanks!
2 Likes
This is a really interesting thread. I’ve noticed this with my mouse as I move it moderately quickly over a series of 2d gui buttons with hover events or over the virtual keyboard. I will adjust the mouse settings tomorrow to see if that fixes it.
I wonder though, @RaananW , if this is responsible for the fps drops I get when moving my vr controller raycaster over the menu at a decent speed!
@gabrieljbaker - WebXR works a bit different. In WebXR we are the ones polling the information ( on each frame). If your browser triggers the pointermove event 100 times every second, the pointer events will be triggered 100 times in babylon as well. As WebXR only emulates pointer events, it happens on each XR frame.
Writing this made me realize that one way to improve the performance here would be to not poll on each frame and allow the developer to define some form of a factor. The meshUnderPointer variable might change a frame or 2 after (well, depending on the factor, actually), but we will poll much less.
I am still looking into the virtual keyboard issue.
2 Likes
