I have to say that I think that I made this kind of test some time ago and it worked properly so maybe something has changed in a recent update.
The expectation is to have a black dot per eye and it works like that in the emulator, but if you test it on a Quest3 or Vision Pro (I have it just for some days) it will fail and more dots per eye will appear.
As I suspected it seems that something has changed, using Firefox and Quest3 is working ok but it fails with Meta Browser so probably it has something to do with an update.
Thank you @RaananW engine.getRenderWidth() did the work (I just have to skip the wMult value).
I tried to explain that my solution worked ok on Quest3 + Firefox but it failed with Quest3 + Meta Browser, also in the past it used to work with Quest3 + Meta Browser.
the quest browser works as expected. The canvas’ width and height are not related to the XR rendering height and width. The engine is updated with the new dimensions when entering (and exiting) XR.
Yes, because it gets triggered when you make a gesture in XR, I can print the values into a UI label so I did it and it says that the engine.getRenderWidth() and engine.getRenderHeight() are 256x256 and obviously that’s madness. Exiting and entering again into XR prints 3800 or whatever the actual resolution.
If I call engine.resize() on IN_XR callback it prints 2048x1782
might be the first frame initializing? I can’t reproduce this in the emulator. I always get 2732:2048.
The thing is - this is the frame buffer rendering width and height (unless you are using layers, which you probably aren’t since they are not supported in the vision PRO AFAIK). which means that if the image you are seeing has a higher resolution than 256x256, this number is incorrect. If you can output this on scene before render, check if there is one output of 256 and then right after a correction. it might be the way apple are dealing with XR init.