This improves the encapsulation and consistency in our WebGL
implementation.
Also allows to implement new methods such as `getShaderSource()`.
It will also allow us to use `delete()` in the destructors of them (note
that we will want to keep track of them from the context).
Borrow the QueueData for WorkQueue::run.
This allows us to get rid of the raw pointers and unsafe dereferencing in
the parallel layout implementation.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6547)
<!-- Reviewable:end -->
layout: Outline the individual property cascading functions to reduce I-cache footprint.
Reduces the size of `properties::cascade` from over 100K of code to
under 5K. Due to the improved I-cache utilization, improves ARM scaling
on 4 cores by 15%.
r? @SimonSapin (feel free to punt to someone else if you like)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6364)
<!-- Reviewable:end -->
I-cache footprint.
Reduces the size of `properties::cascade` from over 100K of code to
under 5K. Due to the improved I-cache utilization, improves ARM scaling
on 4 cores by 15%.
layout: Disable parallel display list building by default.
I've never see it result in a speedup. Actually, I don't think I've seen
it result in anything better than a 50% slowdown. The arithmetic
intensity is just too low, at least with the current algorithm.
Parallel DL building can still be enabled with a debug flag if the
algorithm is improved.
r? @metajack
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6365)
<!-- Reviewable:end -->
Implement crypto.getRandomValues()
Didn't touch mozjs or rust-mozjs because implementing that in the code generator didn't seem too easy. I'm using the same workaround that the TextDecoder does.
Using the OsRng should be the right choice here? As the OS keeps state for us we wouldn't need to have a global rng instance to keep around.
Fixes#4666.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6505)
<!-- Reviewable:end -->
Unit test for util::str::split_html_space_chars
I was concerned for a little bit that passing just whitespace to the
split_html_space_chars function would result in len > 0, so I wrote this
small unit test to make sure it does the right thing. Even though it
does do the right thing, I think there's still value in committing the
unit test.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6553)
<!-- Reviewable:end -->
I was concerned for a little bit that passing just whitespace to the
split_html_space_chars function would result in len > 0, so I wrote this
small unit test to make sure it does the right thing. Even though it
does do the right thing, I think there's still value in committing the
unit test.
Refactor #[jstraceable] to #[derive(JSTraceable)]
fixes#6524. I had to make an additional change not mentioned in the ticket - adding the `#[feature]` to enable deriving custom traits but I assume that's expected at this time.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6529)
<!-- Reviewable:end -->
Reduce dependencies of the `util` crate
Because almost all our main crates depend on util, we should keep its dependencies minimal to increase parallelism and reduce the amount of stuff rebuilt when upstream crates are changed.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6528)
<!-- Reviewable:end -->
