Any way to make GUI resize more exact and faster?

Also it seems like maybe the width is correct but the x position is wrong. :point_down:

1 Like

That’s awesome! Seems to solve the issue! Out of curiosity, is there a reason why checkUpdate is private? Also, I don’t suppose you are available for paid consulting? Check out Moss!

1 Like

Hmmm that’s weird but seems like a much more solve-able issue than the lagging update. Really appreciate the help!


I think since it’s already called each frame it shouldn’t need to be called manually, but in this case that’s the only way I could find to get the timing right… :thinking: (Edit: well, other than overriding the ADT constructor to use a different observable for the update).

PS thanks for the offer but I prob wouldn’t be able to be available very often RN. :slight_smile:

Lol guys I’ve just realised (after putting on my glasses and checking the videos and PGs here again) that you were talking about the issue with the textbox alignment timing issue. I didn’t see it before without my second pair of eyes :roll_eyes: :see_no_evil: That’s why I created that PG with the video.

I was working on this PG and had the same problem with resizing the textboxes with a correct timing (code already removed from the PG)

Sorry :slight_smile:

So of course I implemented the suggested fix and everyone was happy for about a minute until complaints about drastic drop in frame rate when doing a fast zoom. I think in order to keep the frame rate up we will probably have to hide the labels when zooming fast then show them.

Do you happen to have any suggestions?

Oh no, I bet it’s because the GUI is updating twice per frame while zooming, which was the only way I could find to keep it in sync. It makes sense thou with more controls on your actual site it would have a bigger impact… :frowning_with_open_mouth: Tomorrow or next day I can investigate a little more and will post if I discover anything. :slight_smile:

So I found that forcing the root container to do an extra layout seems to keep the GUI in sync just as well, which is much less processing than doing the full update. I’m still not sure why it’s needed thou or what a better/faster way to keep the GUI in sync while zooming would be… Maybe someone else will have more ideas about it but I’m getting stumped now. :slight_smile:

REALLY APPRECIATE the help! This change does improve the performance while keeping the GUI mostly in sync. There is some noticeable delay but much better than the original if not as good as the force update…

What is interesting is if I remove the textWrapping the performance improves even more (we have lots tiles with the GUI labels underneath) which I guess is to be expected…

1 Like

Hey @Matthew_Pflueger @Blake,

@bghgary did some awesome debugging work and helped us narrow down the source of this issue. It looks like _processMeasure needs to be called whenever the view matrix changes. (it’s already called by _checkUpdate in onBeforeSceneRender, but for some reason it needs to be called even earlier than that to keep it in sync.) I made a couple of changes to one of the playgrounds:

Simple GUI in fullscreen mode | Babylon.js Playground (

The main thing is that all we need to do is call _processMeasures on the rect to keep it in sync, rather than needing checkUpdate on the whole ADT.

We definitely want to fix this issue in Babylon GUI, rather that needing a workaround that calls internal functions. I am going to take a look into this further and hope an update by Monday :slight_smile:


This is cool!

1 Like

Just a quick update: we are still investigating the right fix. This issue is harder than we expected - we don’t know yet why _processMeasures resolves the problem. It is definitely in progress, but no update yet.

Poked around and narrowed it down a little more too I think: it seems calling _measure() works just as well as calling _processMeasures(), which calls _measure() among other things…

Also wanted to point out thou that a test PG with more controls might be needed, since calling _checkUpdate was needed to fully keep everything in sync when used in production with lots of controls…

1 Like

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 (

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 Currently with the use of _processMeasure the ellipsis causes a huge FPS drop when zooming in and out.


1 Like

Yes, it will be available in the next beta :slight_smile: 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!