XRDinosaurs webxr experience hangs just after loading #1524
Comments
javifernandez
added
bug
|
This excerpt of the log tells us that the upgrade to gecko 128, applied in this release, might be the culprit of this regression: Hence the |
|
I've been investigating this issue and I've added some debug information, both in Wolvic and Gecko: |
|
I think the main problem is that Wolvic is creating too many textures because gecko returns different Ids everytime it process a new frame. We are storing the textures IDs in a hashmap and we create a new EngineSurfaceTexture instance if the Id is not found. |
|
Analyzing the differences between gecko 121 vs 128, I think the changes in ClientWebGLContext::GetFrontBuffer are key to understand the regression. In 121 the WebGLTextureJS class had 2 attributes to store the owneId and textureId. In 128 the frameBuffer doesn't have those fields and are directly updated in the TextureDescriptor by the graphics process. |
Hmm but why only in this specific WebXR experience? We need those ids for any experience |
No, I don't think the Ids are required for the webxr app at all. It's clear that this specific webxr experience does something different with the GL Context. I've been investigating this further and the problem seems to be related to the fact that Gecko updates the texture handle of the layer_stereo_immersive field. This is where the BrowserWorld::TickImmersive gets the handle to start a new frame. We are getting new handlers all the time, hence creating new EngineSurfaceTextures instances. |
|
BTW, I've bisected the issue with different Gecko versions and the problem started to happen in Gecko 127. |
This patch is the one that is causing the problems in the webxr experience: |
|
I've been investigating the issue and why the changes in the Gecko's color management is causing that the WebXR experience is creating new OpenGL textures for every frame. Still not able to fully understand the reason but this simple change in Gecko avoids the issue: |
|
One of the effects of the simple change described above is that it disables the color manage feature, introduced in the patch that caused the regression, at least in the XR codepath. However, I didn't understood why this may have an imapct on the XR codepath at all, given that XR is not using the new feature at all. I've verified that simply harcoding Hence, hardcoding the SRGB as the initial color space for the created SharedSurface must have another effect that is indeed relevant for the issue and the WebGLContex class's XR codepath specifically. I've found out that in the SwapChain::Acquire method, pooling is disabled if the requested colorspace (SRGB in this case) is different than the one in the pool's top (which is Display, since all the surfaces are created like that). Disabling the pooling seems to the root cause of the issue. |
|
This simple patch also fixes the issue, and shows clearly the its root cause: |
|
Another way of fixing the issue would be to allow the SharedSurface to use the colosr space passed as parameter, as it was the case before the patch with the color management feature was merged: |
Awesome job! Yeah I agree this is the cleanest solution (also the simplest). I'd even send the patch upstream |
|
There is still the question of why only (so far) this specific experience was affected but I guess that's orthogonal to the question and we could figure out later without blocking the fix |
|
Added a new patch for our downstream Gecko, but I'm going to file a bug and propose it for upstream as soon as possible. |
|
I have found out another experience to reproduce this issue; it's the Spiderman game we advertise in our start page. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Configuration
Wolvic version: 1.7.0
Wolvic build ID: 182360411
Hardware: Quest3
Steps to Reproduce
Current Behavior
After a few seconds, the app hungs
Expected Behavior
The experience should be run normally.
Possible Solution
Context
This is a clear regression from 1.6.1
Error Logs and Stack Traces
The text was updated successfully, but these errors were encountered: