-
Notifications
You must be signed in to change notification settings - Fork 217
Render WebVR frames to OVR VR surfaces #1429
base: main
Are you sure you want to change the base?
Conversation
aa0c551
to
6cea36d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates! This is getting closer to be ready!
Other than the mentioned issues WebVR samples demo looks zoomed compared to the master build. It seems something related to bad sizes or bad eye offsets. Could you check that?
ffedf1e
to
e624187
Compare
@MortimerGoro Besides, I notice that if I release my surfaces at |
Looking forward to this being merged! Any progress on resolving conflicts? |
I have solved conflicts in local and am working on other new issues after merging with master branch. |
Awesome. Thanks for the update. Can you comment on whether it helps #1408 in the WebVR samples demo app you show above? Specifically, whether the moving cube (and the stationary cubes if moving your head) appear to judder every few seconds |
52a1b7f
to
0026ebd
Compare
0026ebd
to
94fe049
Compare
I am going to give another commit to provide an UI switch in the developer setting to turn on/off external surface feature. |
Awesome. Thanks again for all your hard work on this. I really appreciate it and look forward to seeing the end result. If you get time, could you please comment on how this feature affects the 'judder' on the moving cubes (and the stationary cubes if moving your head) in the WebVR samples demo on Oculus Quest? |
request a new review again
It seems like I am using wrong surface size when adopting Swapchain surfaces to do immersive render at Sketchfab.com |
Per #304 |
918a522
to
ae782b4
Compare
I'm unclear if this issue is now closed? |
Not yet. We are blocked by Bugzilla review. Sorry about that. |
94fe049
to
ab5f72a
Compare
Now, doing profiling experiments from webgfx-tests, and run it via We can see we can get a little higher FPS if we adopt this approach (enable). The first time to draw or page loading time would be more than the original one (close) is because we need to ask OVR to resize our external surface buffer from the content side, the only way I can get is asking the content thread sleep for However, if we choose to use two external surface buffers. The FPS will be low. It seems like the framebuffer memory pressure (we have a couple of screen size framebuffers) causes the FPS goes down. I have checked disabling all extra JNI bindings and |
…framebuffer textures.
ab5f72a
to
aaa220f
Compare
I put my Gecko work at https://bugzilla.mozilla.org/show_bug.cgi?id=1562134.