remove no-op InitializeCompositing message
I think this is no-op.
---
<!-- 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: -->
- [ ] 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/17685)
<!-- Reviewable:end -->
This patch fixes a couple of issues in the compositor:
1) Remove the delayed composition code. Previously, this would schedule
a composite for 12ms in the future. This doesn't really make any sense
with WR. There's no point in doing a composite unless WR has provided
a new frame to be drawn. This fixes issues in several benchmarks where
we were doing multiple composite / renders per rAF, which is a waste
of CPU time. This *does* make the framerate slower in some cases (such
as a slow rAF callback) but it's more correct - otherwise we were just
compositing the same frame multiple times for no real benefit.
2) Inform the window of the current animation state of the compositor.
Specifically, if an animation (or rAF) is currently active, the
window system switches to use event polling, and does not block on
the OS-level event loop. In the case of active animation, we just
assume that we want to be running as the vsync interval and not
blocking. This means the compositor thread only sleeps on vsync
during animation, which reduces OS scheduling and results in much
smoother animation.
Let the embedder decide if servo should follow a link or not
We want to give a chance to the embedder to handle a link itself.
Is it a problem that this will add a round trip to the main thread every time `load_url` is called?
---
<!-- 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#15655
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because I'm not sure how to test that
<!-- 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/15795)
<!-- Reviewable:end -->
This removes paint threads, rust-layers dependency, and changes
optional webrender types to be required.
The use_webrender option has been removed, however I've left
the "-w" command line option in place so that wpt
runner can continue to pass that. Once it's removed from there
we can also remove the -w option.
Once this stage is complete, it should be fine to change the
display list building code to generate webrender display
lists directly and avoid the conversion step.
This implements system level DPI awareness for Windows. It has three
parts:
1. Add a application manifest which is copied alongside servo.exe during
build that declares our DPI awareness level. This is needed otherwise
DPI queries will return 96dpi and our application will be upscaled on
high DPI displays.
2. Rename hidpi_factor to avoid confusion with Glutin's hidpi_factor
which does something else.
3. Correctly convert windows sizes on window creation for
Windows. Unlike OS X, Windows uses device pixels for window creation.
This changes headless operation to strictly be a runtime option, rather
than a compile-time one. Note that the old headless version still relied
on a display server to support WebGL, while it now requires one all the
time.
Fixes#8573
has loaded.
This avoids a flash of unstyled content, which looks especially bad in
browser.html since unstyled content is white and browser.html has a
transparent background.
Closes#9996.
