Check the BHM option before starting it in multi-process mode.
In multi-process mode, if the BHM option is set start with one otherwise don't.
I didn't add a test for this. However if I should I'd be happy to be pointed to where similar tests are done (meaning tests of options yielding the expected state) because I didn't find my way in all those tests.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#26088
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they are minor enough to not require one.
Delay reftest screenshot while WR frame is rendering
This PR addresses the theory that #24726 occurs when WR is performing an async frame render and the reftest screenshot decides it's time to synchronously read the framebuffer. If there have not been any completed frames rendered yet, that would yield the page background colour.
The changes in this PR introduce an additional layer of synchronization - the compositor stores an AtomicBool value that indicates whether we know that a WR frame has started rendering, which is set to true when an IPC request from layout that submits a new display list is received. This bool is set to false when WR notifies us that a frame has been rendered. The screenshot code refuses to take a screenshot if the bool is true, causing us to delay taking a screenshot until there is no frame pending.
Mechanism to allow Servo to prompt the user
This blocks the embedder thread (compositor thread). Not ideal. I don't think it's too much work to only block script, I'll do that in a follow up bug.
Fix#23376
@Manishearth we have a few new APIs. Hopefully this will cover your needs. A thing I haven't implemented yet is a way to ask the user to pick from a list. Let me know if it's something you'll need.
move `ConstellationCanvasMsg` to canvas_traits and start canvas paint thread
to components/servo. This, however, does not remove dependency for conditional
compilation options.
Ensure SpiderMonkey shuts down cleanly
This is the alternate solution that I described in #24845. Given how much simpler the resulting code is, I'm now much more in favour of this design. Depends on https://github.com/servo/rust-mozjs/pull/487.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#21696 and fix#22276
- [x] There are tests for these changes
Don't panic if surfman initialization fails.
Since WebGL is only one component of the web platform, there's no reason that failing to initialize surfman for webgl support should take down the entire browser.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#24642 (in that the browser will now start up) and fix#24627
- [x] These changes do not require tests because tests for graphics acceleration? don't make me laugh.
Initial implementation of WebGPU API
<!-- Please describe your changes on the following line: -->
- Added the WebIDL bindings for GPU and GPUadapter interfaces.
- Created a background thread for WebGPU api calls.
- Established the async communication between the background thread and the WebGPU interfaces.
- Implemented the `requesAdapter` function of `navigator.gpu`
`./mach test-tidy` reports an error due to the different `arrayvec` version used in `servo` and `webgpu`, so added it to the ignore list in `servo-tidy.toml`
---
<!-- 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
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes addresses a part of #https://github.com/servo/servo/issues/24706
<!-- 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. -->
cc @jdm, cc @kvark
<!-- 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/24708)
<!-- Reviewable:end -->
Issue 23009/separate angle and disable vsync
The `--angle` and `--disable-vsync` options were declared as global options, but only used in the Glutin embedding for desktop builds. Moving them to the Glutin embedding code makes them easier to update in the future.
I modified `opts::from_cmdline_args` to accept a `getopts::Options` (as prescribed in the issue) and augmented `opts::ArgumentParsingResult` to include an `opts::Matches` and `content-process` String when appropriate. I could use some feedback on this last bit. I could have changed the function to return `opts::Matches` and have the embedding code look for the presence of `content-process`, but I felt that the approach I went with was closer to the original design.
The other aspect I'm not sure about is moving `disable-vsync` from a global debug option to a plain embedder option. This changes the command line interface for glutin, which is maybe bad. However I wasn't sure whether it was worth preserving the original behavior given the complexity of injecting debug options into `opts::from_cmdline_args`.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes partially fix#23009 – there are 2 more options to deal with, but I'm not sure if we should handle them yet.
- [x] These changes do not require tests because this is a refactoring and I'm hoping that the existing tests cover these changes.
r? @jdm
