Don't block the script listener thread on window.close().
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 --faster` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
Either:
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because no tangible effect
Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process.
This does not appear to have any effect. I believe this has been the case
since e841065351, when the helper thread was
introduced.
It was added in a7ef1cd35e, where it blocked the
script thread rather than this helper thread.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/11337)
<!-- Reviewable:end -->
This does not appear to have any effect. I believe this has been the case
since e841065351, when the helper thread was
introduced.
It was added in a7ef1cd35e, where it blocked the
script thread rather than this helper thread.
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.
Profile time spent saving the screenshot image
I did this to see if it was a significant factor in automated test runs. (Spoiler: it isn't.)
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/11096)
<!-- Reviewable:end -->
compositor: When WebRender is in use, only composite on new WebRender frames.
Scheduling composition on scroll and so forth is unnecessary and can
cause us to miss frames if the code happens to start the composition
while the WebRender backend is still in the process of preparing the
frame. This is most easily seen when scrolling in full-screen mode in
release builds on Mac.
Closes#9879.
r? @glennw
cc @paulrouget
cc @tschneidereit
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10936)
<!-- Reviewable:end -->
frames.
Scheduling composition on scroll and so forth is unnecessary and can
cause us to miss frames if the code happens to start the composition
while the WebRender backend is still in the process of preparing the
frame. This is most easily seen when scrolling in full-screen mode in
release builds on Mac.
Closes#9879.
add pass-through from doc to http-loader for referrer_policy, ref_URL
add logic for setting referer header
add script pass-through for referrer
add unit tests for setting referer header
Add new compositor message to get scroll_offset;
Add new layout query for computed value of overflow-x/y;
Implement layer_id method for ThreadSafeLayoutNode;
Add new layout query for layer_id;
Implement script interface for getting scrollTop and scrollLeft, as well as relavant helper functions.
In WebRender mode, we were sending two mouse move events: one with the
proper coordinates and one with the wrong coordinates, because of
incorrect fall-through. The script task would usually (but not always,
depending on timing) ignore the first event in favor of the second
event, resulting in incorrect mouse move event coordinates in most
cases.
Closes servo/webrender#238.
Closes#10298.
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.
Previously, the flow for ticking animations was:
Compositor -> Constellation -> Layout -> Script
However, this means that the compositor <-> layout messages can thrash, meaning layout thread is very rarely idle.
This means that the script thread (which joins on the layout thread during reflow) was unable to execute and run rAF callbacks.
With this change, the flow is now:
Compositor -> Constellation -> Script (when rAF is active).
Compositor -> Constellation -> Layout (when transitions / animations are active and no rAF is present).
This makes rAF based animation *much* smoother.
Instead, schedule a delayed composite after each frame of an animation.
The previous code would cause jank, because the following sequence
frequently occurred:
1. The page uses `requestAnimationFrame()` to request a frame.
2. The compositor receives the message, schedules a composite,
dispatches the rAF message to the script thread, composites, and goes to
sleep waiting for vblank (frame 1).
3. The script makes a change and sends it through the pipeline.
Eventually it gets painted and is sent to the compositor, but the
compositor is sleeping.
4. The compositor wakes up, sees the new painted content, page flips,
and goes to sleep (frame 2). Repeat from step 1.
The problem is that we have two composition frames, not just one. This
halves Web apps' framerate!
This commit fixes the problem by scheduling the composite in step 2 to
12 ms in the future. We already have this delayed-composition
functionality in the form of the scrolling timer, which I repurposed and
renamed to the "delayed composition timer" for this task. This change
gives the page 12 ms to prepare the frame, which seems to usually be
enough, especially with WebRender.
Note that simply removing the scheduled composite after rAF is not the
correct solution. If this is done, then pages that call rAF and don't
modify the page won't receive future rAFs, since the compositor will be
sleeping and won't be notified of vblank.
Fixes a bunch of jank in browser.html. The remaining jank seems to be a
problem with browser.html itself.
WebRender is an experimental GPU accelerated rendering backend for Servo.
The WebRender backend can be specified by running Servo with the -w option (otherwise the default rendering backend will be used).
WebRender has many bugs, and missing features - but it is usable to browse most websites - please report any WebRender specific rendering bugs you encounter!
Fixes additional calls to rAF.
Often, a rAF callback will request another rAF from the callback itself.
Previously, the constellation would quickly receive two messages saying
that there were no animations, and then there are animations again in the
situation above. This would make the compositor tick the new animation straight
away, causing strange fluctuations and timings in rAF callbacks.
Instead, only send the NoAnimationCallbacks message if the animation
callback queue is still empty after invoking the callbacks.
This fixes rAF timing, which now runs at the correct (vsync) framerate.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9401)
<!-- Reviewable:end -->
after navigation.
The first bug was that iframes were not reflowed in their parent DOM
when the child page navigated. This is fixed by simply having the
constellation notify the appropriate script thread when navigation
occurs.
The second bug was that the compositor was unable to adjust the pipeline
for existing iframe layers, only new ones. This patch adds logic to do
that.
Closes#8081.
