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 /components/script/dom/bindings/codegen | |
| 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 -->
Diffstat (limited to 'components/script/dom/bindings/codegen')
0 files changed, 0 insertions, 0 deletions