Implement Element.client{Top,Left,Width,Height}
This isn't done, but contains a working implementation of at least `clientTop`. Feedback would be much appreciated: it's probably far from ideal.
Implementing `clientLeft` is straight-forward, I think, but `clientWidth` and `clientHeight` require accessing the `border_box` - and I don't know how that works, yet.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6662)
<!-- Reviewable:end -->
To actually make the multiprocess communication work, we'll need to
reroute the task creation to the pipeline or the compositor. But this
works as a first step.
By doing this on either side of the call to the relevant tasks' start()
method, we don't need to store the mem::ProfilerChan or the reporter
name in the task itself.
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.
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.
Borrow the QueueData for WorkQueue::run.
This allows us to get rid of the raw pointers and unsafe dereferencing in
the parallel layout implementation.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6547)
<!-- Reviewable:end -->
layout: Disable parallel display list building by default.
I've never see it result in a speedup. Actually, I don't think I've seen
it result in anything better than a 50% slowdown. The arithmetic
intensity is just too low, at least with the current algorithm.
Parallel DL building can still be enabled with a debug flag if the
algorithm is improved.
r? @metajack
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6365)
<!-- Reviewable:end -->
Currently, we use UnsafeFlow and UnsafeLayoutNode, both of which are aliases
for (usize, usize) and thus interconvertible. This change should make it
clearer that the WorkQueue is not limited to one particular type.
I've never see it result in a speedup. Actually, I don't think I've seen
it result in anything better than a 50% slowdown. The arithmetic
intensity is just too low, at least with the current algorithm.
Parallel DL building can still be enabled with a debug flag if the
algorithm is improved.
The util component specified fnv and smallvec as dependencies and publicly
reexported both of them. Several other components utilized these reexports,
presumably because fnv and smallvec used to live in the tree so reexporting
made the transition easier.
These indirect dependencies through the util component are unnecessary.
This commit removes the fnv & smallvec crate reexports in the util component.
It exchange, it adds fnv & smallvec as dependencies to non-util components
wherever needed. Finally, it removes the fnv dependency from util as it is not
utilized anywhere in the util component.
`LOCAL_CONTEXT_KEY` is currently a `Cell<*mut LocalLayoutContext>`. The use
of the raw pointer means that the `LocalLayoutContext` is not dropped when
the thread dies; this leaks FreeType instances and probably other
things. There are also some unsafe getter functions in `LayoutContext`
(`font_context`, `applicable_declarations_cache` and
`style_sharing_candidate_cache`) that @eddyb says involve undefined
behaviour.
This changeset changes `LOCAL_CONTEXT_KEY` to
`RefCell<Option<Rc<LocalLayoutContext>>>`. This fixes the leak and also
results in safe getters.
(Fixes #6282.)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6289)
<!-- Reviewable:end -->
`LOCAL_CONTEXT_KEY` is currently a `Cell<*mut LocalLayoutContext>`. The use
of the raw pointer means that the `LocalLayoutContext` is not dropped when
the thread dies; this leaks FreeType instances and probably other
things. There are also some unsafe getter functions in `LayoutContext`
(`font_context`, `applicable_declarations_cache` and
`style_sharing_candidate_cache`) that @eddyb says involve undefined
behaviour.
This changeset changes `LOCAL_CONTEXT_KEY` to
`RefCell<Option<Rc<LocalLayoutContext>>>`. This fixes the leak and also
results in safe getters.
(Fixes #6282.)
* Add parser support for 3d transforms.
* Change ComputedMatrix to a representation that suits interpolation.
* Switch stacking contexts to use 4x4 matrices.
The transforms themselves are still converted to 2d and handled by azure for now, but this is a small standalone part that can be landed now to make it easier to review.
The basic idea is it's safe to output an image for reftest by testing:
- That the compositor doesn't have any animations active.
- That the compositor is not waiting on any outstanding paint messages to arrive.
- That the script tasks are "idle" and therefore won't cause reflow.
- This currently means page loaded, onload fired, reftest-wait not active, first reflow triggered.
- It could easily be expanded to handle pending timers etc.
- That the "epoch" that the layout tasks have last laid out after script went idle, is reflected by the compositor in all visible layers for that pipeline.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6031)
<!-- Reviewable:end -->
The basic idea is it's safe to output an image for reftest by testing:
- That the compositor doesn't have any animations active.
- That the compositor is not waiting on any outstanding paint messages to arrive.
- That the script tasks are "idle" and therefore won't cause reflow.
- This currently means page loaded, onload fired, reftest-wait not active, first reflow triggered.
- It could easily be expanded to handle pending timers etc.
- That the "epoch" that the layout tasks have last laid out after script went idle, is reflected by the compositor in all visible layers for that pipeline.
This implements a simple load-tracking system and tracks stylesheet loads as an example of how it fits together. This is a simplified and rebased version of #3714; I do not believe that the main thrust of hsivonen's comments (related to tracking navigation in browsing contexts) affect this part of the work.
r? @Ms2ger
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/5804)
<!-- Reviewable:end -->
