diff options
| author | bors-servo <lbergstrom+bors@mozilla.com> | 2019-10-17 02:22:31 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-10-17 02:22:31 -0400 |
| commit | 9b59a11b7c11370537b7fcd979c1b455d35262b4 (patch) | |
| tree | 04e59a6a5a5870dbb1c110c47230d204eabf6b27 | |
| parent | 14240bee81bc8b5c5a55d1ed5d5719cf8ee342ee (diff) | |
| parent | 6ce5c25b7230955b7d601135dc7cc7500394d0b0 (diff) | |
| download | servo-9b59a11b7c11370537b7fcd979c1b455d35262b4.tar.gz servo-9b59a11b7c11370537b7fcd979c1b455d35262b4.zip | |
Auto merge of #24408 - servo:jdm-patch-31, 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 -->
| -rw-r--r-- | components/script/dom/xrwebgllayer.rs | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/components/script/dom/xrwebgllayer.rs b/components/script/dom/xrwebgllayer.rs index dabff8fc947..f637f4ee96e 100644 --- a/components/script/dom/xrwebgllayer.rs +++ b/components/script/dom/xrwebgllayer.rs @@ -192,6 +192,9 @@ impl XRWebGLLayer { return Err(Error::Operation); } + // Ensure that we finish setting up this layer before continuing. + context.Finish(); + // Step 10. "Return layer." Ok(XRWebGLLayer::new( &global.global(), |