Add a sampling profiler
This uses the code already built for the background hang monitor and adds the ability to repeatedly sample all monitored threads. This sampling allows us to generate profiles that we can translate into the format used by https://perf-html.io/, allowing us to benefit from modern Gecko performance tooling.
You can run Servo with `PROFILE_OUTPUT=foo.json` and `SAMPLING_RATE=50` (for example), otherwise these values will default to `samples.json` and 10ms, respectively. To activate the profiler, press cmd+p, and to stop profiling, press cmd+p again. This will the captured samples to be symbolicated, which will take a very long time, and eventually there will be a new JSON profile in the output location.
To create a profile for use by Gecko's tools, run `python etc/profilicate.py path/to/profile.json >gecko_profile.json`, and load `gecko_profile.json` in the https://perf-html.io/ to see something like [this](https://profiler.firefox.com/public/8137e2b11fbb92afb80090bc534fd83015c87ee6/calltree/?globalTrackOrder=0-1&thread=1&v=3);
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#13103
- [x] These changes do not require tests because way too many pieces to automate
<!-- 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/23080)
<!-- Reviewable:end -->
#8539 Config preferences backend restructure
<!-- Please describe your changes on the following line: -->
A procedural macro for generating static structures for use as the backend for config preferences, as well a mapping from string names to accessors.
Preferences can be accessed and updated via a map-like interface with `String` keys, and now also via a convenience macro: `get_pref!(path.to.pref)`. Various `serde`-compatible field attributes are also supported, including renaming the string keys. This could be useful when changing the backend structure without breaking existing usages.
I have added the choice to use `i64` as well as `f64` for storing numbers. As it turns out, none of the existing preferences used non-integer values. Setting a floating point value from a command-line argument requires a decimal point in order to parse correctly.
---
<!-- 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
- [X] These changes fix#8539
<!-- 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. -->
-----
I have a few outstanding problems or questions:
1. I am unable to get rid of this warning:
```
warning: unnecessary path disambiguator
--> components/config/prefs.rs:130:51
|
130 | accessor_type = crate::pref_util::Accessor::<Prefs, crate::pref_util::PrefValue>,
| ^^ try removing `::`
```
See: https://stackoverflow.com/questions/54710797/how-to-disable-unnecessary-path-disambiguator-warning
2. Several of the preferences in use were not represented in `prefs.json`. Some of these may be in error, but it is hard to tell. For example `js.offthread_compilation.enabled` vs `js.ion.offthread_compilation.enabled` could be different preferences or could be intended to have the same value.
3. Previously, several pieces of code provided default values when accessing a preference that may not be present. For example:
```Rust
let DBL_CLICK_TIMEOUT = Duration::from_millis(
PREFS
.get("dom.document.dblclick_timeout")
.as_u64()
.unwrap_or(300),
);
```
Fallback values don't really make sense now and I've added these defaults to `prefs.json`. Does this sound right?
4. I have kept `PrefValue::Missing`, though it doesn't seem very useful any more. An error might be more appropriate now for an incorrect preference key. I've kept this partly because [`webdriver_server` uses it](https://github.com/servo/servo/blob/master/components/webdriver_server/lib.rs#L224).
<!-- 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/22923)
<!-- Reviewable:end -->
Remove offscreen_gl_context dependency from canvas_traits and script
This makes it much easier to tinker with rust-offscreen-rendering-context, since it no longer cause a recompile of the script crate.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [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/22992)
<!-- Reviewable:end -->
Use a test VRDisplay that renders to a GL window
<!-- Please describe your changes on the following line: -->
Add a `dom.webvr.test` pref that registers a new VR display, which registers to a GL window.
The matching webvr PR is https://github.com/servo/rust-webvr/pull/66.
---
<!-- 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
- [X] These changes fix#22795
- [X] These changes do not require tests because we need a followup PR to support reftests which use the VR display
<!-- 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/22953)
<!-- Reviewable:end -->
Use simpleservo embedding API for Magic Leap
This removes the duplication between the two ports and makes it easier to improve all of our embeddings simultaneously.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#22065
- [x] These changes do not require tests because no automated tests for embedded devices.
<!-- 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/22871)
<!-- Reviewable:end -->
Allow the embedder to register their own VRServices
<!-- Please describe your changes on the following line: -->
Allow the servo embedder to register their own `VRService`s, not just the default ones.
---
<!-- 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
- [X] These changes fix#22878
- [X] These changes do not require tests because this is all plumbing
<!-- 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/22886)
<!-- Reviewable:end -->
Initial webrtc and getUserMedia DOM support
This is able to reach the point where connections are properly negotiated and ready to exchange streams.
<s>The `toJSON()` stuff doesn't work yet, so most example code will need to be tweaked to manually construct JSON first before sending SDP and ICE messages over websockets. I'll add support for this soon. (This may need webidl tweaks to support `[Default]` and `toJSON()`)</s>
For some reason I haven't yet figured out, connections are one-way, Servo is able to receive streams but the other end doesn't see the streams Servo sends. I don't think this is due to https://github.com/servo/media/issues/191, but that bug is making it harder to test.
This implementation simply drops streams that it receives, without connecting them up to any output elements, since servo-media-player doesn't yet have mediastream support.
Since servo can neither effectively send nor receive streams this implementation isn't useful yet, however it is getting large and I figured I'd get it reviewed and landed early as a base.
r? @jdm
<!-- 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/22780)
<!-- Reviewable:end -->
Update rust-mozjs
These changes adjust our uses of the rust-mozjs APIs to accommodate the changes in https://github.com/servo/rust-mozjs/pull/450.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#22342.
- [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/22353)
<!-- Reviewable:end -->
