Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSynchronize WebGL layer creation with underlying GL APIs #24408
Conversation
highfive
commented
Oct 9, 2019
|
Heads up! This PR modifies the following files:
|
highfive
commented
Oct 9, 2019
|
|
jdm
changed the title
|
Given my previous explanation of what's going on, this change feels like a workaround for a deeper problem. The rAF isn't invoked until after the XRWebGLLayer constructor returns, so any webgl commands should still be ordered correctly when the first rAF callback occurs. |
jdm
changed the title
|
@Manishearth see if this makes the gl errors go away for you? |
|
Oh wait, there's no ordering problem - the DOM exception and the GL errors happen in different threads. Any GL operations invoked from the script thread would be invoked after the XRWebGLLayer's operations are complete. |
|
Confirmed that webxr-broken.html (which I've updated to use |
|
r=me, idk if the WIP is "still need to test" or "unsure if this is the right approach" |
|
Is there something blocking merging this? |
|
The WIP was "unsure if this is the right approach". I'm still not convinced that it's not papering over some other issue. |
|
Based on my analysis in #24373 I think this is a sensible way to deal with this issue. |
jdm
changed the title
|
@bors-servo r=Manishearth |
|
|
Synchronize WebGL layer creation with underlying GL APIs I believe the underlying cause of #24373 is that the XR callbacks can end up executing before the XR WebGL layer setup has occurred. This was observed in the following symptom: * a DOM exception would be thrown from inside the renderVR function, which is only called from XR's requestAnimationFrame callback * following this, the webgl thread would panic with a GL error when executing the GL operations invoked from XRWebGLLayer::Constructor This indicates that _somehow_ the XR rAF callback that raised an exception would have been operating on GL state that was not actually the state intended. <!-- Reviewable:start --> This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24408) <!-- Reviewable:end -->
|
|
|
@bors-servo retry |
|
|
Synchronize WebGL layer creation with underlying GL APIs I believe the underlying cause of #24373 is that the XR callbacks can end up executing before the XR WebGL layer setup has occurred. This was observed in the following symptom: * a DOM exception would be thrown from inside the renderVR function, which is only called from XR's requestAnimationFrame callback * following this, the webgl thread would panic with a GL error when executing the GL operations invoked from XRWebGLLayer::Constructor This indicates that _somehow_ the XR rAF callback that raised an exception would have been operating on GL state that was not actually the state intended. <!-- Reviewable:start --> This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24408) <!-- Reviewable:end -->
|
|
jdm commentedOct 9, 2019
•
edited
I believe the underlying cause of #24373 is that the XR callbacks can end up executing before the XR WebGL layer setup has occurred. This was observed in the following symptom:
This indicates that somehow the XR rAF callback that raised an exception would have been operating on GL state that was not actually the state intended.
This change is