Current page load telemetry probes are insufficient in performance RUM testing. FX_PAGE_LOAD_MS_2 will stop the timer when the user switches tabs or navigates off the page, while the current navigation probes include all content including about:blank, about:newtab, moz-extension, etc. This patch adds support for the following probes which do not suffer from those limitations:
PERF_PAGE_LOAD_TIME_MS
PERF_PAGE_LOAD_TIME_FROM_RESPONSESTART_MS
PERF_DOM_CONTENT_LOADED_TIME_MS
PERF_DOM_CONTENT_LOADED_TIME_FROM_RESPONSESTART_MS
PERF_FIRST_CONTENTFUL_PAINT_MS
PERF_FIRST_CONTENTFUL_PAINT_FROM_RESPONSESTART_MS
PERF_REQUEST_ANIMATION_CALLBACK_PAGELOAD_MS
PERF_REQUEST_ANIMATION_CALLBACK_NON_PAGELOAD_MS
Differential Revision: https://phabricator.services.mozilla.com/D94004
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
This creates a marker that starts when an observer is added and ends when it is removed.
If there are multiple observers at the same time, their markers overlap.
The current profiler markers API only lets us insert the marker once we know
both the start and the end timestamp. This means that, if a profile is captured
in the middle of a refresh observer's observation period, there will not be a
marker for that observer in the profile. This can be improved once we have a way
to emit separate start and end markers and a way to associate the correct markers
with each other (bug 1661114).
Differential Revision: https://phabricator.services.mozilla.com/D91059
This patch includes a couple of changes.
1) Notify contentful paint only during refresh driver ticks.
2) Not only the root document, sub document should also have their own
contentful paint entry.
3) Consider invisible text as contentful as well.
Differential Revision: https://phabricator.services.mozilla.com/D89498
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415
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
