Implement WebGLContext resize
<!-- Please describe your changes on the following line: -->
Related PR: https://github.com/servo/webrender/pull/519
Implement WebGLContext resize (canvas.width & canvas.height). I have tested:
- Fixes WebGL apps that initialize canvas size after calling canvas.getContext("webgl")
- Support WebGL apps that change the canvas size & viewport on window.onresize
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- 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/14075)
<!-- Reviewable:end -->
switch to using webrender_traits::ImageData
update use of webrender_traits::StackingContext in layout
use webrender_traits::channel::msg_channel in webgl ipc
fix use of resource_override_path in components/servo/lib
FBO status is supposed to depend on the size of the attachments all
matching, so we need to re-check when it changes. We don't ensure
matching yet, but this will prevent regressions when we do.
This is part of general GL behavior: when an object is deleted, look
through the currently bound objects and detach the deleted object from
them. Detaching an object from an FBO causes it to need to be
re-checked for its status.
This is not a complete implementation yet: It doesn't clear the
contents of the renderbuffer on creation. However, Gecko's plan to
only clear renderbuffers when the first FBO using them is the
simplest.
Once FBOs are allowed, we were running into testcases that deleted the
active FBO, and expected the following ReadPixels to come from the
default framebuffer.
texture-size-limit.html is using a large array for all of its calls at
various sizes, and we were throwing errors on the calls that should
have passed.
These new functions are derived from the existing uniform*fv
functions. They get used in a lot of demo code, so it should greatly
improve our compatibility.
This regresses uniformMatrixBadArgs.html, which gets at an existing
problem in our uniform matrix support (failure to validate that the
uniform is a matrix before calling down) but previously just failed
because it only called the 'fv' variants and never the existing 'f'
variants.
This is a step with multiple intentions:
* Be correct.
* Unlock tests that are blocking @anholt.
* Ease the transition to typed arrays once the changes by @Ms2ger start rolling
in, since I expect the amount of test expectations to update to be
non-trivial.
webgl: Add isProgram() support.
<!-- Please describe your changes on the following line: -->
webgl: Add isProgram() support.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
There's one failure still, where a deleted program should still be
considered to be a program until it's unbound. However, I recently
made it so that we unbind at delete time, and we may need to partially
back that change out.
<!-- 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/13102)
<!-- Reviewable:end -->
webgl: Do validation of glScissor/glViewport(width, height) on the DOM side
<!-- Please describe your changes on the following line: -->
webgl: Do validation of glScissor/glViewport(width, height) on the DOM side
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Avoids testcase CRASHes due to unexpected GL errors.
<!-- 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/13060)
<!-- Reviewable:end -->
There's one failure still, where a deleted program should still be
considered to be a program until it's unbound. However, I recently
made it so that we unbind at delete time, and we may need to partially
back that change out.
We keep bindings that shadow what's mapped in the GL state currently,
and so we need to remove the objects from our binding points when they
get implicitly removed from the GL binding points during object deletion.
On a GLES or compatibility underlying GL context, we were fine because
an underlying renderbuffer object would just get re-created, and
nothing too bad happened because we aren't tracking the currently
bound renderbuffer at the DOM level. However, on a desktop GL core
context, binding non-genned or deleted names is an error.
Fixes a crash in object-deletion-behavior.html.
To do this, we need to keep a map of GL names (encapsulated as
WebGLFramebufferId) to WebGLFramebuffer objects so that we can return
the right type.
Fixes#12852
The VertexAttrib[234]fv compare to the same size as in their function
name. This wasn't noticed becacuse this function isn't connected from
the .webidl yet.
