Thank you, this discovery helped me identify the root of the problem!
Basically, the Control’s _moveToProjectedPosition function, which keeps the control in sync with the mesh, was using last frame’s width/height measurements because _processMeasures isn’t called until the _layout function, which happens later on in the scene rendering process.
The fix is just to call _processMeasures before moving the control! It was a super small change.
PR is open now: [GUI] Fix lagging by darraghjburke · Pull Request #11991 · BabylonJS/Babylon.js (github.com)
Thanks for all your help investigating this!
1 Like
BTW, please let me know if you are still seeing lag in production with large numbers of controls after you get this change. I think this should fix the problem but I haven’t tested it
1 Like
Hi! I see that the PR is merged. Will it be in the next beta release?
Calling _processMeasure ourselves seems to be working well with hundreds of meshes (around 600 meshes each with a label). With the fix, should we remove our use of _processMeasure?
Anyway, I really appreciate all the help and quick responses from everyone. Amazing!
The next performance challenge on our radar is using label.textWrapping = BABYLON.GUI.TextWrapping.Ellipsis with hundreds of meshes (line 80 of https://playground.babylonjs.com/#XCPP9Y#11108). Currently with the use of _processMeasure the ellipsis causes a huge FPS drop when zooming in and out.
Thoughts?
1 Like
Yes, it will be available in the next beta 
You shouldn’t need to call _processMeasures anymore. I’m glad to hear that it’s working well for you!
Hmm, I’ll definitely look into that and see what I can do. Do you mind opening a new thread about it since this one is already quite long?
1 Like
Hi! Finally got around to testing this and it seems to work well for us! Really appreciate the help!
2 Likes