P2 removed IsTimerPrecisionReductionEnabled and thus removed the check for RFP
pref. While most ReduceTimePrecision* functions are fine with that because
GetTimerPrecisionType checks that, the two ReduceTimePrecision*RFP functions
miss the check.
This patch mainly cover the check for that two functions and rename them to
*RFPOnly since they only use RFP when the pref is on.
Depends on D64324
Differential Revision: https://phabricator.services.mozilla.com/D66734
--HG--
extra : moz-landing-system : lando
To support checking CrossOriginIsolated in performance.now(), we need to:
- Add new types to TimerPrecisionType for nsRFPService
- System, HighResAllowed are added
- All is renamed to Normal
- Introduce a set of Reduce methods which require isSystemPrincipal and
CrossOriginIsolated to be passed and decide the TimerPrecisionType later
- Original Reduce methods should only be called when callsites know the
TimerPrecisionType. Otherwise, they should call the new methods.
- The following patches will use new methods
Differential Revision: https://phabricator.services.mozilla.com/D63293
--HG--
extra : moz-landing-system : lando
This avoids a bunch of ugly casts and void pointers, without much overhead
(unlike std::function or such).
Differential Revision: https://phabricator.services.mozilla.com/D68182
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
The key here is to test the type of the variable declaration for being a
smartptr type, instead of testing the type of the variable _use_.
Differential Revision: https://phabricator.services.mozilla.com/D65581
--HG--
extra : moz-landing-system : lando
`GetProfileTimelineSubDocShells` was using nsIDocShellTreeItem to walk the
DocShells that are visible and recording profile markers. This change switches
to using `BrowsingContext` for the walk, and ignores OOP iframes as they aren't
painting in the current process.
Differential Revision: https://phabricator.services.mozilla.com/D63960
--HG--
extra : moz-landing-system : lando
The patch removes the tad odd interleave behavior from the main thread and makes RefreshDriver to give
at least a tiny bit time for non-high priority tasks.
Given the recent change to have similar block-until behavior in child and parent process, this should work
consistently in all the processes.
Differential Revision: https://phabricator.services.mozilla.com/D63098
--HG--
extra : moz-landing-system : lando
Because the code becomes more generic, the following renames are done:
mLastChildTick is renamed to mLastTick
mLastProcessedTickInChildProcess is renamed to mLastProcessedTick
To clarify which member variables are used in parent process only
mRefreshTickLock is renamed to mParentProcessRefreshTickLock and
new variables mRecentParentProcessVsync and mPendingParentProcessVsync are
added. (mRecentVsync and mRecentVsyncId don't anymore have the different
behavior in parent and child processes)
The basic idea is to keep the vsync compression in parent process in
NotifyVsync.
(In child processes it is handled by IPDL/IPC compression).
The main functionality change is in ParentProcessVsyncNotifier::Run.
That method doesn't anymore call mObserver->TickRefreshDriver(...)
but mObserver->NotifyParentProcessVsync(...), which then calls
NotifyVsync(...) on the main thread. That way parent process gets the
same vsync block-until behavior as what child process has.
Depends on D62032
Differential Revision: https://phabricator.services.mozilla.com/D62033
--HG--
extra : moz-landing-system : lando
Because the code becomes more generic, the following renames are done:
mLastChildTick is renamed to mLastTick
mLastProcessedTickInChildProcess is renamed to mLastProcessedTick
To clarify which member variables are used in parent process only
mRefreshTickLock is renamed to mParentProcessRefreshTickLock and
new variables mRecentParentProcessVsync and mPendingParentProcessVsync are
added. (mRecentVsync and mRecentVsyncId don't anymore have the different
behavior in parent and child processes)
The basic idea is to keep the vsync compression in parent process in
NotifyVsync.
(In child processes it is handled by IPDL/IPC compression).
The main functionality change is in ParentProcessVsyncNotifier::Run.
That method doesn't anymore call mObserver->TickRefreshDriver(...)
but mObserver->NotifyParentProcessVsync(...), which then calls
NotifyVsync(...) on the main thread. That way parent process gets the
same vsync block-until behavior as what child process has.
Depends on D62032
Differential Revision: https://phabricator.services.mozilla.com/D62033
--HG--
extra : moz-landing-system : lando
"Scripts" wasn't making any sense for this marker and it was nearly imposssible
to understand. It should be "requestAnimationFrame callbacks" instead.
Differential Revision: https://phabricator.services.mozilla.com/D60229
--HG--
extra : moz-landing-system : lando
It dispatches a DOM event so that it should be marked as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D55801
--HG--
extra : moz-landing-system : lando
Lets Wayland sessions run vsync off wayland surface frame callbacks by creating
an interface for widgets to return a local VsyncSource, if applicable.
This interface is currently used for the compositor, and for refresh drivers
in the parent process. It is not yet used for vsync in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D28430
--HG--
extra : moz-landing-system : lando
VRManager only be accessible in the parent or GPU process. So, in the tab process, isPresenting() will always return false. In WebVR immersive mode, we need to skip layer painting and don't need to wait for painting because the compositing is already done in WebGL.
Differential Revision: https://phabricator.services.mozilla.com/D48119
--HG--
extra : moz-landing-system : lando
When we had it in the loop, we would continually reduce it, which held the
possibility of bumping it down an epoch due to double imprecision. Now
we only reduce it once, using all rAF callbacks get the same timestamp.
Differential Revision: https://phabricator.services.mozilla.com/D44526
--HG--
extra : moz-landing-system : lando
In Bug 1387894 we created a mode for Firefox where it unconditionally clamps all timestamps to 20 microseconds. This happens if you disable privacy.reduceTimerPrecision (which is on by default) and is so we don't inadvertently leak super-high-resolution (nanosec) timestamps.
As part of that patch, we started clamping animation timestamps - which are exempted from privacy.reduceTimerPrecision because it was too difficult to get them working at the time. (We should still fix that though.)
This caused new test failures, and one of those was a comparison between document timelines and the timestamp in requestAnimationFrame. we were not clamping the timestamp in requestAnimationFrame under the logic that it fires in predictable intervals.
However discussions about the WPT change we made to 'fix' the now-broken comparison https://github.com/web-platform-tests/wpt/pull/18172 and https://github.com/web-platform-tests/wpt/pull/18357 showed me that document.timeline is supposed to be slaved to the requestAnimationFrame timestamp (or vice versa.)
The correct fix is therefore to unconditionally clamp the requestAnimationFrame timestamp AND the document.timeline timestamp. In doing so we also start clamping/jittering the requestAnimationFrame timestamp in Resist Fingerprinting mode, so that might cause some new/unexpected behaviors for that mode we should watch out for.
Differential Revision: https://phabricator.services.mozilla.com/D43788
--HG--
extra : moz-landing-system : lando
Rather than short circuit the refresh driver, this instead only bypasses painting on
Android when WebVR is in immersive mode.
Differential Revision: https://phabricator.services.mozilla.com/D42973
--HG--
extra : moz-landing-system : lando
Removes vsync.parentProcess.highPriority pref and stores BrowserTabsRemoteAutostart() directly into sHighPriorityEnabled.
Differential Revision: https://phabricator.services.mozilla.com/D42962
--HG--
extra : moz-landing-system : lando
Collect telemetry for the number of pending style and layout flush requests per
flush and the number of style and layout flushes per nsRefreshDriver::Tick. A
style flush reports only style requests, but a layout flush reports style and
layout requests since flushing layout implies a style flush also.
Differential Revision: https://phabricator.services.mozilla.com/D40756
--HG--
extra : moz-landing-system : lando
Converts layout.idle_period.required_quiescent_frames and layout.idle_period.time_limit to static prefs. These are the last prefs in nsLayoutUtils::initialize(), but since the function still calls nsComputedDOMStyle::RegisterPrefChangeCallbacks() the commit retains it.
Differential Revision: https://phabricator.services.mozilla.com/D41856
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
For a slow tick, where the processing time takes longer than 1/60th sec, record
telemetry for the percentage of that time spent in each sub-system processing
Events, Style), Reflow, Display and Paint.
Differential Revision: https://phabricator.services.mozilla.com/D38962
--HG--
extra : moz-landing-system : lando
