Make it possible for iframes to create their own pipeline ID.
This doesn't change any functionality, but it's the first step towards removing SubpageId.
Adding this change now will allow us to gradually change over code referencing subpage id rather than in one massive PR.
Introduces a namespace for pipeline ID generation - there is a namespace for the constellation thread, and one per script thread.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7807)
<!-- Reviewable:end -->
This doesn't change any functionality, but it's the first step towards removing SubpageId.
Adding this change now will allow us to gradually change over code referencing subpage id rather than in one massive PR.
Introduces a namespace for pipeline ID generation - there is a namespace for the constellation thread, and one per script thread.
StackingContexts are added to layers when it is necessary to maintain
their ordering on top of other layered StackingContexts. Instead of
tracking the information about a layer scattered around into different
structs, combine it all into LayerInfo. LayerInfo will be used in the
future to hold layer information for DisplayItems that are layerized
independently of StackingContexts.
each iframe.
The old code that attempted to do this during layout wasn't able to work
for multiple reasons: it couldn't know where the iframe was going to be
on the page (because of nested iframes), and at the time it was building
the display list for a fragment it couldn't know where that fragment was
going to be in page coordinates.
This patch rewrites that code so that both the sizes and positions of
iframes are determined by the compositor. Layout layerizes all iframes
and marks the iframe layers with the appropriate pipeline and subpage
IDs so that the compositor can place them correctly. This approach is
similar in spirit to Gecko's `RefLayer` infrastructure. The logic that
determines when it is time to take the screenshot for reftests has been
significantly revamped to deal with this change in delegation of
responsibility.
Additionally, this code removes the infrastructure that sends layout
data back to the layout task to be destroyed, since it is now all
thread-safe and can be destroyed on the script task.
The failing tests now fail because of a pre-existing bug related to
intrinsic heights and borders on inline replaced elements. They happened
to pass before because we never rendered the iframes at all, which meant
they never had a chance to draw the red border the tests expect to not
render!
Closes#7377.
A few small bits of refactoring to prepare for more advanced DisplayList layerization
This will be useful when PaintLayers that contain DisplayLists instead
of StackingContexts need to draw themselves. This is a simple
preparatory refactoring and doesn't change any behavior.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7710)
<!-- Reviewable:end -->
Previously, StackingContexts might have a PaintLayer. We switch the
ownership, for several reasons:
* We want PaintLayers to potentially contain something other
than a StackingContext soon.
* We want to delay the creation of PaintLayers until the last
minute, so that we can synthesize new layers for sandwiched
content.
This commit also implements the second goal. Instead of creating
PaintLayers during layout itself, wait until we are sorting and
layerizing a completed DisplayList.
Split out layered child stacking contexts in display lists
This patch is in preparation for more dynamic layerization of the
pieces of display lists. It also prevents having to sort the children
by z-index multiple times.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7392)
<!-- Reviewable:end -->
This patch is in preparation for more dynamic layerization of the
pieces of display lists. It also prevents having to sort the children
by z-index multiple times.
Known issues:
* Display list optimization can sometimes optimize out elements that
should be shown. This affects the Enyo demo.
* The `overflow: scroll` container doesn't clip the inner layer properly
when borders, border radius, etc. are present.
* `overflow-x: scroll` and `overflow-y: scroll` don't work individually;
elements are scrolled all at once.
* Scrolling only works on absolutely-positioned elements.
Now GLRasteizationContexts require having an active GLContext. This will
allow preserving GLContexts and possibly framebuffers between
rasterization sessions, improving GL Rasterization performance.
Linux Before:
+ Painting Per Tile 4.5559 4.3392 1.6920 18.5548 74
Painting 170.1554 151.8353 0.0008 350.1093 28
Linux After:
+ Painting Per Tile 3.8726 3.1299 1.5848 12.6732 62
Painting 13.5480 10.8947 0.0029 39.1198 23
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.
profile: Make the time and memory profilers run over IPC.
Uses a couple of extra threads to work around the lack of cross-process
boxed trait objects.
r? @nnethercote
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6629)
<!-- Reviewable:end -->
We currently store LayerBuffers, because previously NativeSurfaces did
not record their own size. Now we can store NativeSurfaces directly,
which saves a bit of space in the surface cache and allows us to create
LayerBuffers only in the PaintTask.
This also means that instead of sending cached LayerBuffers, the
compositor can just send cached NativeSurfaces to the PaintTask.
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.
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.
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.
* 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.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6214)
<!-- Reviewable:end -->
* 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.
Example output from the memory profiler:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.26 MiB -- display-list
| 0.78 MiB -- paint-task # new output line
| 0.78 MiB -- buffer-map # new output line
```
The buffer maps aren't huge, but they're worth measuring, and it's good
to get the memory profiler plumbing into PaintTask.
