This telemetry was trying to measure three things:
* The time spent during style / layout in a tick. This is useful.
* The times SetNeed{Style,Layout} flush have been called. This is not a
particularly useful metric, there's not much to learn or change from
it. Any call is basically free as long as they're consecutive /
there's no flush in between.
* The number of times layout / style has been flushed during a tick.
This is more useful than the above but, similarly, there's not too
much to be learned here. Number of flushes can be completely
orthogonal to how expensive it has been.
It also had a number of flaws:
* It is recorded per-PresShell, so we get multiple pings per tick.
* Similarly, if a sub-frame dies before the tick, we just never report
that time.
Instead, refactor it to make it simpler, and just record the first
metric reliably. This simplifies the code substantially, and I don't
think we're losing much.
The histograms are also expired. We might want to renew this, I'll file
a follow-up to either properly renew this if we plan to look at it, or
remove the code entirely from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D210907
We should be more consistent about what stuff runs and what doesn't when
the pres context is getting torn down...
MANUAL PUSH: Trivialish orange fix CLOSED TREE
Not sure how testable this is, for a11y purposes. The other consumer is
some XRSession stuff which doesn't seem to care too much about the
timing of this.
Differential Revision: https://phabricator.services.mozilla.com/D210384
This doesn't change behavior intentionally, though it annotates places
where our code doesn't match the spec right now, and adds comments and
quotes the HTML spec in the relevant places.
Some things that this highlights:
* Resize steps are fired at the wrong time.
* Some of our animation stuff seems sketchy / out of place too to me
(AnimationTimeline observes the refresh driver at the style phase).
* Focus fix-up is out of order (that's known, bug 1788741 for tests).
* Our layout flush stuff should probably be better integrated / closer
to the resize observer loop.
* Display observers are run before stuff like ResizeObserver runs. That
might be a problem for accessibility's NotificationController?
Again, these are intentionally not addressed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D210279
There's no call to AddRefreshObserver(FlushType::Layout), so we don't
need to track layout flushes. The only reason we need
mLayoutFlushObservers is so that reflows triggered from the style flush
get processed. But at that point, we can just flush layout directly.
There's no really good distinction between style flushes and layout
flushes with container queries anyways, so this makes the code simpler
to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D209924
The CSS Box Sizing specification indicates that last remembered sizes
are recorded "at the time that ResizeObserver events are determined and
delivered" [1].
In bug 1807253, we changed the implementation of when proximity to the
viewport of `content-visibility: auto` nodes are determined and of when
resize observations are broadcast, in order to align with the latest
version of the HTML specification [2]. We continue to use an internal
`Document::mLastRememberedSizeObserver` to update last remembered sizes
but it has been causing issues (e.g. bug 1867090 and bug 1880928) and
could be replaced by a direct update before broadcasting resize
observations.
This is what the current patch is doing. The elements currently observed
by `Document::mLastRememberedSizeObserver` are now stored on a
`Document::mElementsWithLastRememberedSize` hashset and a new function
`Document::UpdateLastRememberedSizes` is called before broadcasting
resize observations, and peforms the work of `LastRememberedSizeCallback`
and of `CalculateBoxSize` (with `aBox=Content_box`).
The only behavior change is in the `while(true)` loop from
`DetermineProximityToViewportAndNotifyResizeObservers`: at each step
we update the last remember sizes for elements of arbitrary depth, and
don't use these depths for calculating `shallowestTargetDepth`. This is
fine, since our `LastRememberedSizeCallback` only records current box
sizes without causing significant side effects (e.g. execution of
JavaScript code) that may require a relayout.
[1] https://drafts.csswg.org/css-sizing-4/#last-remembered
[2] https://html.spec.whatwg.org/#update-the-rendering
Differential Revision: https://phabricator.services.mozilla.com/D202571
Most are brought over straightforwardly, their Telemetry callsites reworded
to use Glean, with mirroring to the Telemetry probes taken care of by the Glean
Interface For Firefox Telemetry (see the telemetry_mirror property).
There were two special cases: PERF_DOM_CONTENT_LOADED_FROM_RESPONSESTART_MS,
and PERF_DOM_CONTENT_LOADED_MS. Both were removed as they were unused.
Differential Revision: https://phabricator.services.mozilla.com/D200867
This is unfortunately somewhat hard to test, because paint suppression
is not really quite observable by the page.
This makes sure that we don't report resize observations etc until the
page has been laid out for other reasons.
Differential Revision: https://phabricator.services.mozilla.com/D194910
The basic idea is to check if there are pending tasks also right after RefreshDriver tick has been handled, not only before tick.
But in this new case we can't predict how much time is needed for other tasks, so just a bit of time is given.
The patch tweaks also other things: CanDoCatchUpTick (which is used by catch-up ticks and FinishedWaitingForTransaction) should
return false if the active timer is blocked because of mSuspendVsyncPriorityTicksUntil.
And to make it easier to check whether driver is blocked, mSuspendVsyncPriorityTicksUntil is changed to rely on local time, not the time stamp
from vsync.
The low priority notify is changed so that it uses member variables from the driver and in case it does trigger a tick, it uses the most recent skipped
values.
Differential Revision: https://phabricator.services.mozilla.com/D193409
Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
The basic idea is to check if there are pending tasks also right after RefreshDriver tick has been handled, not only before tick.
But in this new case we can't predict how much time is needed for other tasks, so just a bit of time is given.
The patch tweaks also other things: CanDoCatchUpTick (which is used by catch-up ticks and FinishedWaitingForTransaction) should
return false if the active timer is blocked because of mSuspendVsyncPriorityTicksUntil.
And to make it easier to check whether driver is blocked, mSuspendVsyncPriorityTicksUntil is changed to rely on local time, not the time stamp
from vsync.
The low priority notify is changed so that it uses member variables from the driver and in case it does trigger a tick, it uses the most recent skipped
values.
Differential Revision: https://phabricator.services.mozilla.com/D193409
This patch doesn't change behavior; it just removes some redundant checks.
(Note that the tight-scoping around nsAutoMicroTask/ReduceAnimations is
important for the RAII object to be torn down at the intended time; but it
doesn't need its own if-check.)
Depends on D191909
Differential Revision: https://phabricator.services.mozilla.com/D191911
This patch doesn't change behavior.
This is a bit gross, but it helps us make better use of the backtrace to figure
out what's going on in a given crash report.
Differential Revision: https://phabricator.services.mozilla.com/D191909
This doesn't affect behavior; it's just a pure refactoring, moving code from
being inline to being in a helper function.
Differential Revision: https://phabricator.services.mozilla.com/D191908
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
Based on testing we can simplify the current setup and also ensure that we don't trigger a RefreshDriver tick too soon
(so that we don't get two ticks when we expect only one).
This gets us even closer to Chrome's raf handling.
Differential Revision: https://phabricator.services.mozilla.com/D190361
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Note, I'm deleting the null-check from UpdateIntersectionObservations, since
I'm essentially hoisting it up one level (and I don't think there's anything
that could null out mPresContext in the intervening code).
Differential Revision: https://phabricator.services.mozilla.com/D190367
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
These days it's just a very thin wrapper over an nsTArray of
ResizeObservers. We also schedule notifications for resize observations
for the whole BrowsingContext tree at once, so there's no point on
individually keep track of them.
Differential Revision: https://phabricator.services.mozilla.com/D190113
We use a PerformanceHintSession where supported to ensure the content
process main thread and stylo threads are scheduled at a high
priority. Previously we created the session when the
VsyncRefreshDriverTimer is started, and destroyed the session when it
is stopped (after a timeout).
This patch instead moves the creation and destruction to ContentChild
based on the process priority. This more accurately reflects the
conditions under which we want the session to be active.
Differential Revision: https://phabricator.services.mozilla.com/D188477
This massive hack shouldn't be needed after the previous patch, and
throttling of in-process and out-of-process should be consistent now.
Differential Revision: https://phabricator.services.mozilla.com/D185809
