We can have markers with empty cause stacks, if we keep the timer running
without calling EnsureTimerStarted() again.
Differential Revision: https://phabricator.services.mozilla.com/D85457
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
nsRefreshDriver's NotifyVsync method had some slightly convoluted logic: Based on the thread it is called from, it would guess whether it is called from a vsync source, in which case it would schedule itself onto the main thread, or from the self-scheduled task, in which case it would perform work.
This just splits the two: NotifyVsync only takes care of VsyncSource, and schedules a task that calls the tick logic. This also allows Wayland to run the VsyncSource off the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D77044
This tends to happen in content processes only, but per the commit
message from bug 1542808, we don't provide a widget-specific vsync
source in content processes currently.
Differential Revision: https://phabricator.services.mozilla.com/D70641
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
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
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
`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
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
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
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
"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
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
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
