Oculus Browser perf regressions

[dmarcos]

It doesn’t seem A-Frame specific. I’ve seen several reports recently affecting all WebVR content (references below). @DigiTec @Artyom17 Any known bugs or regressions? Anything we should do on our side?

https://www.reddit.com/r/OculusQuest/comments/c6p3d5/jitter_judder_stutter_in_the_oculus_browser/?utm_source=share&utm_medium=ios_app

https://www.reddit.com/r/OculusQuest/comments/c8zet5/please_help_with_a_quick_oculus_quest_experiment/?utm_source=share&utm_medium=ios_app

https://github.com/supermedium/issues/issues/16

[avaer]

I tried https://webvr.info/samples/03-vr-presentation.html on Quest Oculus Browser and I am seeing visual frame misses. This is despite the simple scene and the counter showing a smooth 72 FPS. So I think this is indeed a browser frame timing problem.

I tried the same code in Exokit native and it's buttery smooth so this seems to be a timing bug rather than something in the OS/device.

[kennardconsulting]

Thanks @modulesio for confirming this works in other native browser engines such as Exokit. So hopefully it can be fixed in the Oculus Browser?

[kennardconsulting]

Interestingly, this issue also happens on Firefox Reality on Quest (when sideloaded via APK)

[kennardconsulting]

@modulesio can you please provide hints how you installed Exokit native on the Quest? The documentation is a bit confusing for me.

[avaer]

@kennardconsulting Can you open a documentation issue in the Exokit repo?

That request is not really related to this A-Frame issue.

[kennardconsulting]

@modulesio yes sorry - I was just trying to reproduce the 'buttery smooth' experience you described. How did you get that running? I tried sideloading the exokit.apk that they have on their home page (https://get.exokit.org/android) but it ran horribly and crashed after a few minutes

[avaer]

You have to build the APK yourself; there haven't been any official releases for a long time since the alpha.

[kennardconsulting]

Okay thanks, I will investigate. Any chance you could attach your APK for the webvr.info sample here? The Firefox Reality guys would like to see it as a comparison

[arpu]

looks like oculus go have new chrome 74.0.3729.182

[arpu]

@modulesio do you had the problem with this version?

[avaer]

This is still bugged on my Quest, but I'm not sure how the browser updates on that device.

[nrgapple]

@modulesio Can you post link to your built apk?

[avaer]

Old, broken releases are here: https://github.com/exokitxr/exokit/releases, but you are encouraged to build yourself for recent code.

[nrgapple]

I couldn't find the instructions for building for android (quest)

[avaer]

There is a build script for the Android tool chain here: https://github.com/exokitxr/exokit/blob/master/scripts/oculusmobile/build-android.sh

[kennardconsulting]

@nrgapple here is a built Exokit APK. Instructions:

1. Download from https://drive.google.com/file/d/1t6JrFvH8eUT0oAc9Zd37j485jCes6dA1/view?usp=sharing
2. adb install -r app-debug.apk
3. adb shell am start -n com.webmr.exokit/android.app.NativeActivity -e ARGS "'node --experimental-vm-modules /package -x webvr https://webvr.info/samples/03-vr-presentation.html'"

If stay still and watch the moving cube, it is nice and smooth on Exokit.

The latest findings (from the Firefox Reality team) is that both Oculus Browser and Firefox Reality show '6 stale frames per second'. We believe this is causing the choppyness.

However, could you please confirm that you don't see the choppyness in this Exokit version, and that the Exokit version doesn't have stale frames?

[Galadirith]

@kennardconsulting I've attached a few screen captures from some test I ran. I have used a minimal A-Frame site for testing but it should be clear from the screen captures that the issue is not with A-Frame, it's just that A-Frame was the quickest and simplest way to set up some reproducible tests. I haven't included any screen captures from Firefox Reality on the quest because it exhibits the same behaviour as Oculus Browser.

Versions

Oculus Browser: 66.0.3359.203 (80e77ab) Firefox Reality: 1.4 (e6ec2b6) Exokit: Build from https://github.com/aframevr/aframe/issues/4222#issuecomment-515224054

com.oculus.browser@https://webvr.info/samples/XX-vr-controllers.html

You can see the choppy performance in this WebVR example with the controllers

com.webxr.exokit@https://webvr.info/samples/XX-vr-controllers.html

You get smooth performance with Exokit, however it's clear that Exokit it not able to render everything correct for example the brown controller vector and the blue background are missing.

com.webxr.exokit@https://aframe-4222.glitch.me/

This is a really minimal A-Frame example with background sphere, plane and controllers (https://glitch.com/~aframe-4222). Again smooth performance from Exokit. A sphere is used to fake a background because Exokit does not correctly render the background component in A-Frame.

com.webxr.exokit@https://aframe-4222-stats.glitch.me/

This example is the same as the previous but now adds an fps counter (aframe-fps-counter-component). You see here that Exokit running at a much lower fps. It also does not correctly render the fps counter over the left controller that you will see in the com.oculus.browser example next. The fps-counter component (by way of the stats) is known to add additional computation, but it shouldn't have an impact on such a simple scene.

com.oculus.browser@https://aframe-4222-stats.glitch.me/

Here you see the same subtle choppyness for Oculus Browser.

---

Exokit does seem to be smoother than Oculus Browser and Firefox Reality. But it's not clear if this is just because it's missing features. It is not rendering pages correct unlike Oculus Browser and Firefox, and it seems to not be as performant. So even though it might not be exhibiting choppyness with random stale frames, it will consistently perform at a lower fps when given a reasonable load compared to Oculus Browser and Firefox that handle content well (albeit with the random stale frames).

I hope this is useful 😊

[dmarcos]

@Galadirith Thanks for investigating. Can you also try with A-Frame master? https://cdn.jsdelivr.net/gh/aframevr/aframe@ab9821761340fd6ee28171fc38f85a45c2ade514/dist/aframe-master.min.js

A-Frame master enables 72Hz mode on Oculus Browser that was one of the causes of judder.

[Galadirith]

@dmarcos of course no problem. Unfortunately I'm still getting almost the same behaviour across the board. With test site https://glitch.com/~aframe-4222-ab98217 and https://glitch.com/~aframe-4222-stats-ab98217 I still see the random stale frames in Oculus Browser and Firefox Reality and no perceivable stale frames in Exokit.

One difference was the fps-counter. When running with the fps-counter in v0.9.2 the actual counter disappears occasionally (as the screen capture showed). This didn't happen with ab98217, the counter was always visible, but still seemed to have random stale frames.

The other difference is that Exokit fails to run the ab98217 test site with the fps-component

./adb shell am start -n com.webmr.exokit/android.app.NativeActivity -e ARGS "'node --experimental-vm-modules /package -x webvr http://aframe-4222-stats-ab98217.glitch.me/'"

I'd be happy to post some more screen captures if you think they would be useful, although I don't think they show anything different to https://github.com/aframevr/aframe/issues/4222#issuecomment-541419871.

If I can do anything useful please let me know, I'd be happy to capture some performance data or anything else that could help figure out this issue. Even though it's not an A-Frame specific issue, it still affects A-Frame.

I remembered the RecRoom devs did have a similar issue on the Quest when it was originally released

Fixed an issue that would make your hands appear jittery… we just had something screwed up, sorry :-/

- Rec Room UPDATE - the "Rainbow Connection" Edition by magglerockk

It's possible it's completely unrelated, and I can't find any info on what exactly was broken in their earlier release, but maybe contacting the RecRoom devs might give some useful insight? 😊

[kennardconsulting]

@Galadirith this is absolutely outstanding bug reporting. Yes, this is exactly the issue. Thank you so much for documenting it so thoroughly. Note the A-Frame fps-counter is (IMHO) poorly implemented and unreliable. You may want to try something like: https://github.com/supermedium/superframe/issues/236

@dmarcos I really want to stress this is nothing to do with 60Hz vs 72Hz. I know your intentions are good, but you've said this on several different posts around the Web, and it's really a red herring that may be stopping the right people (i.e. Oculus team) from investigating further.

[kennardconsulting]

@Galadirith could you please add your voice to this Oculus bug report: https://developer.oculus.com/bugs/bug/386106122259513/

[Artyom17]

Hey, sorry guys, completely missed this issue. I'll try to repro the issue and investigate. Doesn't seem like it is a perf issue since it maintains FPS at 72....

[Artyom17]

A quick test reveals that GC kicks in for both cases - A-Frame and XX-VR-Controller. This is the A-Frame: And memory growth is pretty significant: Will continue investigation.

[dmarcos]

@Artyom17 Thanks for helping. Let us know if you need us put together more test cases or help with anything.

[Artyom17]

After more investigation, found out that VSyncs are delivered quite unstably. Currently, WebVR/XR in Oculus Browser is using Android Choreographer to generate VSyncs and seems like this is not the best way. Probably, will use 'end-of-frame' signal from our VrDriver instead.

[dmarcos]

Thanks for the update! Available to help if you need

[kennardconsulting]

@Artyom17 this is the most positive development on this bug in the 3 months since it was raised. Thank you so much for stepping up and investigating. Really excited for a fix!

[kennardconsulting]

Hi @Artyom17 - did switching to 'end-of-frame' signal from VrDriver help?

[Artyom17]

@kennardconsulting : yes, I am getting much smoother rate now. I am finalizing the fix now.

While working on this issue, I found another one: a separate issue of controllers-related jitter. The issue is that controller's poses are predicted for the certain frame, while gamepad polling logic has no idea which pose it is picking up at the moment. So, sometimes it picked up wrong poses for the controllers which caused jitter for the controllers' rendering (while the rest of animation / head movement is still smooth). I am working on fixing that.

All of these fixes will be available in Oculus Browser 7.0 (can't give any release ETA yet, but we would be able to provide early access to it as soon as it is stabilized). Note, it will also have WebXR enabled by default (most likely), therefore A-FRAME must be on the latest THREE.JS (r109 and up) to continue to work (even as WebVR: the earlier versions of 3js already has implementation of older WebXR spec which is incompatible with the latest public draft and 3js picks up WebXR over WebVR if it detects WebXR support; i.e. 3js will try to use broken WebXR implementation and will most likely throw an exception and fail). It is not Oculus-specific issue: this will happen in any WebXR-enabled browser.

[dmarcos]

@Artyom17 Thanks for the fix and the heads up. It's super appreciated. I just bumped THREE to r109 on master and tested WebXR on latest Chrome. Everything working as expected. We should be all set. If someone wants to play with it. Links can be found in the CI commits: https://cdn.jsdelivr.net/gh/aframevr/aframe@fb322bc51e38272b3afa927a293c5844bdc3782c/dist/aframe-master.min.js

[Artyom17]

@dmarcos - I'll test WebXR A-Frame with Oculus Browser.

[Galadirith]

@Artyom17 Thank you so much for all your work to identify and fix these issues 👍 I'll fork some examples/test cases to use A-Frame master with the THREE.js@r109 changes from @dmarcos. If I can be of any help, I would be very glad/excited to test out an early access release of Oculus Browser 7.0 when it's stabilised.

[Artyom17]

@dmarcos Just FYI, r109 is still using deprecated WebXR method 'supportsSession', r110 should be fully complaint with using proper 'isSessionSupported'.

[klausw]

AFrame makes its own call to supportsSession, independently of three.js: https://github.com/aframevr/aframe/blob/master/src/utils/device.js#L22

I've changed it to support both variants as part of my immersive-ar PR: https://github.com/aframevr/aframe/pull/4281/files#diff-ba471abca77be75dc382488219889eb4R34

FYI, Chrome will continue to implement supportsSession for a bit to ease the transition, with a console warning that it's obsolescent.

[Artyom17]

FYI, Chrome will continue to implement supportsSession for a bit to ease the transition, with a console warning that it's obsolescent.

Same for Oculus Browser, btw.

[dmarcos]

Is this still an issue? Can we close?

[kennardconsulting]

I think we all agree it's not an A-Frame issue. But we won't know if it's fixed until @Artyom17 and team push out something for us to test.

[kennardconsulting]

Hi @Artyom17 any update?

[Artyom17]

Yes, Oculus Browser 7.0 is in beta channel right now. You can send me your oculus ids to gmail.com email (the first part is the same as my name here) then I could add you to the beta channel. ETA for the release - beginning of the December.

[Artyom17]

Just one thing: OB 7 will have WebXR enabled by default, but this, unfortunately, will break any WebVR experience which is based on pre-109 3JS (i.e. all A-Frame experiences). You would need to go to chrome://flags and disable WebXR to run these broken WebVR experiences.

[kennardconsulting]

@dmarcos does this mean we'll need a new A-Frame release before December or OB 7 will break all existing experiences? @Artyom17 I thought we had previously agreed "Chrome will continue to implement supportsSession for a bit to ease the transition"

[Artyom17]

@kennardconsulting : supportsSession is fine and will be supported. This is in 3JS r109. However, as far as I can see current A-Frame 0.9.2 is based on 3JS r102, am I correct? The master A-Frame is based on r109 and will work.

[dmarcos]

@Artyom17 Thanks for the heads up. @kennardconsulting 0.9.3 is expected on Dec 6th but you can now start using master that supports both WebVR and WebXR. Let us know if you have any issues.

[kennardconsulting]

Great result!

• can confirm OB 7 breaks 0.9.2. Can also confirm master fixes it
• can confirm OB 7 is significantly smoother in 03-vr-presentation, both the animation of the cube and translating your head
• can confirm text attached to the camera in A-Frame is now much smoother when moving your head

Thanks so much @Artyom17

[kennardconsulting]

@Galadirith can you re-test? On my app, everything ran much smoother. However, after a period (about 3 minutes) I experienced the same old judder again. It lasted about 30 seconds, and then things returned to being smooth. This was quite possibly just my app. But would be interested in you doing an extended test?

[kennardconsulting]

@Artyom17 can you confirm if the memory growth issue you saw (above) has also improved?

[Artyom17]

The judder / jitter may have different reasons and unfortunately not all of them are fixable on a browser side. The performance induced judder could be diagnosed via DevTools: just measure how long the frame takes, it shouldn't be more than 13.5 ms for 72Hz or 16.5 ms for 60Hz. The garbage collection hickup is also close to impossible to solve, but it should not take more than 1-2 frames every now and then. What I've fixed in 7.0 were two actual bugs - one with improper timing frames in general and another one, the controller related - grabbing incorrect pose for the VR controllers (which caused judder for the controllers only).

Note, the beta channel is going to be updated with newer versions periodically (till the actual release).

[dmarcos]

@Artyom17 Is WebVR going to be deprecated right of the bat on OB 7 or are WebVR / WebXR going to coexist for a bit? Notice that all the content featured in the browser at the moment will break. It would be nice if we can give a heads up to developers and have a transition period. I believe Firefox is going to keep both WebVR and WebXR for a bit.

[Artyom17]

@dmarcos WebVR is NOT going to be deprecated in 7.0 (or any 7.x version). WebVR and WebXR are going to coexists in Oculus Browser for some time, we don't have clear plan or ETA for sunsetting WebVR yet.

[dmarcos]

@Artyom17 That’s awesome. Thanks for the info. It will give us some time to help the A-Frame community transition to WebXR