Functions like BuildDisplayListForStackingContext or BuildDisplayListForChild look
up EffectSet property several times in callees, such as IsTransformed() or
HasOpacity(), which is time wasting.
We should look up EffectSet just once, and pass the found one to all callees
that need it.
MozReview-Commit-ID: GZywm2UcpU7
--HG--
extra : rebase_source : 21f5dd0076a90d876a6df35eee2b886844b44f0a
FRAME_STATE_BIT of nsFrame and nsINode::mBoolFlags are both full, we need to
find another place to hold MAY_HAVE_OPACITY information.
nsINode::mSlots might be a choice, but since we always use this information in
painting, memory footprint of nsINode will become larger after this change.
So I decide to put this information right in EffectSet. The drawback of storing
this information in EffectSet is, although unnecessary Effect look-up is
prevented, we still need EffectSet property look-up in each time
HasOpacityInternal call, so we need Part 2.
Conceptually, Part 1 and Part 2 are independent.
MozReview-Commit-ID: 6sfBFSHjxQb
--HG--
extra : rebase_source : 394141cec3b44bb352297a0add8f9763d815bddb
This prevents short-lived processes when we are not at the maximum normal content process count and the new window's first tab is not going to load in that remote type.
This ensures that we never get a short-lived process for the new tab, which can happen if we are not at the maximum for that remote type.
We also set the correct remoteType.
This change means that any related http pages driven through content (window.open, links, etc.) will continue to be loaded in the file content process.
Same-origin loads via the UI will also remain in the file content process.
Cross-origin loads via the UI will cause a process switch.
History navigation will stay in the process, if it was originally loaded in that process.
This flag is for when we've loaded a URI in a remote type that is not the default
for compatibility reasons (for example related http in the file content process).
So that we can load the history entry in that same process as well.
We are seeing occasional failed release assertions from calling
animation.startTime().get_TimeDuration() in SampleAnimationForEachNode on
Windows.
My theory is that in some circumstances (perhaps graphic-driver related?) when
creating a layer transaction we fail to call Layer::StartPendingAnimations and
end up sending pending animations to the compositor. Prior to bug 1334583 that
would have only triggered a debug assertion so it may have gone unnoticed if it
depends on the system configuration.
This patch makes us check that the startTime is set before we try to access it
in order to avoid triggering a release-time assertion. If the startTime is not
set we will use the hold time which should give us the correct behavior for
a still-pending animation. (Furthermore, the holdTime is set unconditionally
when we create animations so it should be correct -- but even if it were not
set explicitly, its initial zero value would still likely produce a reasonable
result until the start time was updated on a subsequent layer transaction. At
very least, it should not crash. Likewise, if it was set to an incorrect value.)
This patch also strengthens the debug assertion in SampleAnimationForEachNode to
check that not only is start time not-null, but that it is set to a TimeDuration
since MaybeTimeDuration also includes a third uninitialized "None" state.
<!-- Please describe your changes on the following line: -->
This PR implements the current draft Houdini Worklets specification (https://drafts.css-houdini.org/worklets/).
The implementation is intended to provide a responsive environment for worklet execution, and in particular to ensure that the primary worklet executor does not garbage collect, and does not block loading module code. The implementation does this by providing a thread pool, and performing GC and module loading in a backup thread, not in the primary thread.
---
<!-- 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 fix#16206
- [x] There are tests for these changes
<!-- 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. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: ac99a48aeaa184d3acdb39d249636a140c4b7393
--HG--
rename : servo/components/script/dom/webidls/Function.webidl => servo/components/script/dom/webidls/VoidFunction.webidl
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : d4069e68d5b007ec258bf5821d6386a3ec63c490
Rebuild the one-off search buttons when the theme changes. See bug 1357800 for details. Summary: On Linux, switching between themes can cause a row of buttons to disappear.
MozReview-Commit-ID: 8lfsUO00jYP
--HG--
extra : rebase_source : 5bdef5513a8c8f8f02fd9383867b0ed57610b606
This restores the code to what it was doing prior to bug 1360241 (where
the else to add to mWildRules was an else of a test of fType), but then
removes the unnecesary null-check on the result of GetFrameTypeInfo.
MozReview-Commit-ID: EOPumJoKrIs
--HG--
extra : transplant_source : %E4%C8%A7%21%98%FAx%C7%1E%A5%0D%B5-%C5%BA%80%D4%1C%A8M
I've been bitten by spidermonkey tasks not running on automation enough.
Anything that can have an influence on spidermonkey builds should
trigger them to build, not only js/ changes.
As it turns out, the sm-package task has a more complete list of things
spidermonkey depends on, so we just use that same list for all tasks.
--HG--
extra : rebase_source : 609ba99fadec0d024266975ce143a26e23bc0d78