Add support for filtering WebGL extensions based on WebGL version
<!-- Please describe your changes on the following line: -->
Add support for filtering WebGL extensions based on WebGL version
---
<!-- 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 _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- 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/19040)
<!-- Reviewable:end -->
Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
http://www.robohornet.org gives a score of 101.36 on master,
and 102.68 with this PR. The latter is slightly better,
but probably within noise level.
So it looks like this PR does not affect DOM performance.
This is expected since `Box::new` is defined as:
```rust
impl<T> Box<T> {
#[inline(always)]
pub fn new(x: T) -> Box<T> {
box x
}
}
```
With inlining, it should compile to the same as box syntax.
In a later PR, DomRoot<T> will become a type alias of Root<Dom<T>>,
where Root<T> will be able to handle all the things that need to be
rooted that have a stable traceable address that doesn't move for the
whole lifetime of the root. Stay tuned.
I don't want to do such a gratuitous rename, but with all the other types
now having "Dom" as part of their name, and especially with "DomOnceCell",
I feel like the other cell type that we already have should also follow
the convention. That argument loses weight though when we realise there
is still DOMString and other things.
The pref `webgl.testing.context_creation_error` will cause creation of a new WebGLRenderingContext to fail, iff set to true.
Also update test expectation of `context_creation_error.html` to pass.
Make canvas origin clean checks use origin of image response
Adapted from #15887.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#15409
- [X] There are tests for these changes
<!-- 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/16913)
<!-- Reviewable:end -->
We were setting it to whatever value from {1,2,4,8} the user requested
and otherwise ignoring it. There were two problems there:
1) Validation ignored it, so GL could read outside of the user's array
in TexImage() or TexSubImage() if the aligment was greater than
cpp.
2) TexImage()/TexSubImage() from image/canvas sources wasn't packing
its data according to the unpack alignment.
To fix this, start tracking the user-requested alignment in the DOM
side of the context. Set the GL's alignment to 1 for image/canvas
sources or the user's value for array sources, and pass the user's
alignment in to validation so that it can figure out the correct size
of image that the GL will ready.
The code was returning RGBA8 data from the non-raw sources (HTML
canvas elements, JS ImageData, etc.), but we then validated and passed
that rgba8 data as if it was whatever format/datatype was specified in
TexImage2D/TexSubImage2D, so the pixels would come out as garbage.
It would seem like we could just rewrite the passed in format/datatype
for the TexImage call to be RGBA/UNSIGNED_BYTE, but that would leave
incorrect levels of precision if the internalformat didn't match the
format/datatype (and older desktop implementations often ignore the
internalformat in choosing their internal format, anyway).
