This commit introduces the `serde` dependency, which we will use to
serialize messages going between processes in multiprocess Servo.
This also adds a new debugging flag, `-Z print-display-list-json`,
allowing the output of display list serialization to be visualized.
This will be useful for our experiments with alternate rasterizers.
GLRasterizationContext is now responsible for doing GPU rasterization.
It can coexist with its target NativeSurface, so we don't have to
continually recreate NativeSurfaces when doing GPU rasterization.
process parts.
This will make it easier to adapt to IPC.
The trickiest part here was to make script tasks spawn new layout tasks
directly instead of having the pipeline do it for them. The latter
approach will not work in multiprocess mode, because layout and script
must run in the same address space and the pipeline cannot inject tasks
into another process.
an IPC channel instead.
Because this used a boxed trait object to invoke messages across a
process boundary, and boxed trait objects are not supported across IPC,
we spawn a helper thread inside the compositor to perform the marshaling
for us.
Move LayerBuffer cache to the compositor
Now that NativeDisplay can be shared between the compositor and the
paint task, we can move the LayerBuffer cache to the compositor. This
allows surfaces to be potentially reused between different paint tasks
and will eventually allow OpenGL contexts to be preserved between
instances of GL rasterization.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6530)
<!-- Reviewable:end -->
Now that NativeDisplay can be shared between the compositor and the
paint task, we can move the LayerBuffer cache to the compositor. This
allows surfaces to be potentially reused between different paint tasks
and will eventually allow OpenGL contexts to be preserved between
instances of GL rasterization.
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 -->
Update to latest rust-layers
The compositing context, painting context and display metadata have all
been collapsed into a single NativeDisplay class.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6525)
<!-- Reviewable:end -->
html5ever now uses the Tendril string type to minimize copying internally,
but Servo still converts from/to `String` at the boundary
(which involves copying).
Use a faster scroll speed under X11
Platforms may report scroll deltas either in
chunks/lines/rows or pixels, depending on the
platform API and device capabilities.
If the platform reports a line/chunk-based delta
then the application needs to convert the delta
into a suitable number of pixels. Apple's documentation for example states
that the app should interpret the delta as a number of lines or rows to scroll,
depending on the type of view.
This commit just hardcodes it to 57 as
a starting point which matches the value that
Firefox calculates as the max char height
for the root frame on my system.
This depends on this Glutin PR: https://github.com/tomaka/glutin/pull/483Fixes#5660
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6373)
<!-- Reviewable:end -->
Platforms may report scroll deltas either in
chunks/lines/rows or pixels, depending on the
platform API and device capabilities.
If the platform reports a line/chunk-based delta
then the application needs to convert the delta
into a suitable number of pixels.
This commit just hardcodes it to 57 as
a starting point which matches the value that
Firefox calculates as the max char height
for the root frame on my system.
Fixes#5660