You’re creating a full screen (canvas sized) texture, and since you’re passing in adaptiveScaling as true, on my Macbook that’s doubling the resolution of the texture that’s allocated. Once you call linkWithMesh(), it’s now going to need to redraw the whole texture and upload it to the GPU on each frame. It appears that this is slow on Safari, but efficient enough on Chrome to not cause noticeable delay.
Do you really need such a big texture for your scenario? If you tell me more about your plans we may be able to find another approach that’s more efficient for your use case.
You could also file a bug report on Safari asking them to improve the performance of the upload of textures from a Canvas to the GPU, using this playground as a repro.
Hi @amoebachant thanks for your reply. In our case, we’d like to have a consistent visual size of the GUI elements defined at fixed pixel width/height when changing the hardware scaling level with engine.setHardwareScalingLevel(…).
For instance, in the previous playground, we have this result in a high DPR screen when “adaptiveScaling=false”:
Of course we can multiply that GUI element height by the screen DPR to get the correct size (that way the performance seems to not affected), but I thought that adaptiveScaling was already doing that (and would help us simplify our app code in some other areas as when reducing/increasing the hardwareScalingLevel due to optimizations for instance).
Thanks for the additional info! I’d suggest opening that bug against Safari to make this operation more efficient while you use another approach in the meantime. I know this behaves a little differently, but you may also want to check out the new MSDF text rendering - here’s a sample with labels tracking meshes in the scene: https://playground.babylonjs.com/#9YCDYC#6
Sorry to necro this post but…
It seems that when we updated to BJS version 8.22.1 there where some sort of breaking change to the ADT or GUI elements.
A bunch of our text in Frame seems to have “shiftedUp”. Things seemed fine at 8.16 or the version right before the Audio engine changes.
I’m wondering if its related to this?
I was digging on the commit history and I saw:
Which is the only thing I can think of that changed about ADTs and GUIs that deals with positioning of controls between the version we had working and the current most up to date version.
Our settings where false for adaptToDeviceRatio and whatever is default for adativeScaling
That bug fix was for a situation where the size of the text area was sometimes being measured using the default font size, and in other cases with the requested font size. It’s possible that it is related, because if the height of the word wrapped text was calculated incorrectly here, it could result in this vertically squished text, but I’m not able to reproduce this and without seeing the code I can’t be sure they are related.
Could you provide a repro of the issue in a playground so I can investigate further?
Glad to hear it! I was just locally testing adding the ignore flag back in and confirmed that would reintroduce the perf issue that change was meant to address. So did the text boxes have insufficient height before you turned on resizeToFit then? It may be that it just happened to work before because of the missing _applyStates() call, but it’d be good to know for sure. If you still think there’s a bug here, please make a playground repro and I’ll investigate it. Thanks!
I tried to make a playground to repo it and failed XD….
We have a ton of custom components that extend the base ones to tie in our behaviors api so its a little rough. But oddly enough when I migrated all of it to the PG, what renders in the PG is different then what renders in our frame context. So I’m assuming its on us.
This is the migrated elements, but for some reason its not showing the same layout even with the same numbers applied. That makes me think its for sure a timing issue on us.
All these components where made like four years ago before I was with Frame, so it might just be that I need to go over them all and fix them up to “correct” conventions.
