Refactor Layout 2020 layout for a compositor-side scroll tree
This change refactors how layout is done in Layout 2020 in preparation for a compositor-side scroll tree:
1. Now the SpatialId and ClipId of each fragment is stored separately. This will allow storing a scroll node id instead of only the handle to the WebRender spatial node.
2. Separate out stacking context tree construction and display list building. This change will make it possible to eventually build the stacking context tree without the full display list if we find that necessary. For instance, this might be useful to cache containing block boundaries.
3. Add a `DisplayList` struct that stores both the WebRender display list builder and the compositor info. This exposes the API to the layout thread for display list building.
In addition, this change adds a lot of missing documentation. This should not change behavior.
<!-- Please describe your changes on the following line: -->
---
<!-- 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 do not require tests because they do not change behavior.
<!-- 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. -->
This change refactors how layout is done in Layout 2020 in preparation
for a compositor-side scroll tree:
1. Now the SpatialId and ClipId of each fragment is stored separately.
This will allow storing a scroll node id instead of only the handle
to the WebRender spatial node.
2. Separate out stacking context tree construction and display list
building. This change will make it possible to eventually build the
stacking context tree without the full display list if we find that
necessary. For instance, this might be useful to cache containing
block boundaries.
3. Add a `DisplayList` struct that stores both the WebRender display
list builder and the compositor info. This exposes the API to the
layout thread for display list building.
In addition, this change adds a lot of missing documentation. This
should not change behavior.
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
Safari does this. This reduces the runtime in the example linked from
comment 0 quite a lot (40ms on a local opt build, from ~130ms on a
release nightly build).
I added a pref because there's a slight chance of performance
regressions on pages that do not use attribute selectors, as we're now
doing more unconditional work per element (adding the attributes to the
bloom filter). But the trade-off should be worth it, I think.
Differential Revision: https://phabricator.services.mozilla.com/D111689
No behavior change, just cleanup. Actually seem this technically _adds_ some code even
though it's a cleanup, but that's mostly because of the wrapping of the
derive list. The resulting code is simpler (more in-line with our usual
things, so I think it's an improvement).
Differential Revision: https://phabricator.services.mozilla.com/D111551
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
There's no reason we can't just query LookAndFeel and we need to use
sSystemMetrics. In the past, LookAndFeel queries were not cached, but
this is no longer the case, so perf wise should be pretty equivalent.
Note that we don't need the NS_SUCCEEDED checks because the default
value from GetInt if the platform doesn't support it is 0 anyways.
Differential Revision: https://phabricator.services.mozilla.com/D110805
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
To know the valid rules for each property, we need to put this information
into the Servo prop list and add an appropriate getter to Longhand/Shorthand.
Differential Revision: https://phabricator.services.mozilla.com/D105825
Starting with macOS 10.14, the generic light/dark vibrancy is deprecated, and semantic vibrancy names are preferred.
If we ever need more vibrancy, we can add new values with semantic names.
Depends on D107910
Differential Revision: https://phabricator.services.mozilla.com/D108152
The reason why this doesn't work is because these styles come from
datetimebox.css, which is really an author style.
We could special-case these elements, but the approach that the CSSWG resolved
on for the new forced-colors spec is to respect system colors specified by
authors, see:
https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties
So this moves us towards that, and fixes the issue nicely.
Differential Revision: https://phabricator.services.mozilla.com/D108321
And remove the windows-specific versions of this color.
Also fix the hard-coded defaults by the colors I get in the default windows
theme.
Differential Revision: https://phabricator.services.mozilla.com/D108325
This should be both a memory and speed win for pages using a lot of
Shadow DOM.
In order to make the cache properly work we need to start keying media query
results on the actual StyleSheetContents, as that's what we share on Gecko, but
that should all be fine.
Differential Revision: https://phabricator.services.mozilla.com/D107266
It was clarified that the percentages are weights, and two weights are
now allowed. Missing percentages are computed as 100% - the other or
50%. Other than that, commas are required etc, which is good since
that's how I implemented it originally.
Differential Revision: https://phabricator.services.mozilla.com/D107295
This is straight-forward and builds on the color animation code. This
implements only the <percentage> syntax, not the whole <color-adjuster>
syntax, which seems fairly more complex.
Of course, this only uses sRGB because that's all the colors we support,
but it should be feasible to extend to lab() / lch() colors once we
support those.
I believe this subset of syntax is useful and worth implementing, so
people can play with it and say if it's useful.
Differential Revision: https://phabricator.services.mozilla.com/D106698
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
