nsRefreshDrivers belonging to fully-loaded documents in content processes
now correctly stop their timer when no observers are present.
Differential Revision: https://phabricator.services.mozilla.com/D28339
--HG--
extra : moz-landing-system : lando
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
So, this patch makes all caller of it safe including its arguments unless
they come from other methods.
Differential Revision: https://phabricator.services.mozilla.com/D27225
--HG--
extra : moz-landing-system : lando
As per the following change to the HTML spec:
86b05f8a07
when running a requestAnimationFrame callback it should be possible to cancel
another requestAnimationFrame callback scheduled to run in the same frame by
using cancelAnimationFrame.
See issue:
https://github.com/whatwg/html/issues/4359
Differential Revision: https://phabricator.services.mozilla.com/D20974
--HG--
extra : rebase_source : 696dde4f205f2d12a67a4e9649d629a0f4e7de27
In the next patch in this series we want to compare the handle of frame
callbacks we are about to run, with a set of canceled handles stored on the
document. This patch makes us pass the handles along with the callbacks so we
can do that.
Incidentally doing this allows us to just swap array elements when building up
the refresh driver's set of callbacks to run. That is hopefully a little more
efficient than running the implicit conversion operator on each item and then
appending to an array.
Differential Revision: https://phabricator.services.mozilla.com/D20973
--HG--
extra : rebase_source : f014605ece1c8e3495b2927621fb9f72ff8e57d7
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
fcp is often almost blank paint, but the next couple paints have more content.
But in order to not regress page load time, reduce frame rate later during the page load.
Differential Revision: https://phabricator.services.mozilla.com/D24636
--HG--
extra : moz-landing-system : lando
The Timestamp implementation on Windows seems to be based off of two system APIs: GetTickCount64 and QueryPerformanceCounter. QPC seems to be preferred over GTC, unless a "failure" in QPC is detected.
There is code in the Timestamp implementation to detect if QPC "fails" be comparing elapsed time of QPC to elapsed time of GTC.
Through logging on try server I observed the following in different failures:
1) the QPC failure detection kicks in a lot and disables use of QPC
2) the QPC of the vsync timestamp was in the future compared to the QPC of TimeStamp::Now().
3) the QPC of TimeStamp::Now() was missing (presumably because it was disabled) and the GTC of the vsync timestamp was in the future compared to the GTC of TimeStamp::Now()
4) the vsync timestamp printf of raw GTC and QPC values matched at the source (SoftwareDisplay::NotifyVsync) and in the refresh driver, so the vsync timestamp wasn't getting messed up.
I guess we could spend more time on the error detection in our Windows TimeStamp code, but this failure is only happening on 32-bit machines.
Here's a patch to disable the assertions on 32-bit Windows. Depends how important we think this assertion is relative to the work to investigate more.
Differential Revision: https://phabricator.services.mozilla.com/D22453
--HG--
extra : moz-landing-system : lando
As per the following change to the HTML spec:
86b05f8a07
when running a requestAnimationFrame callback it should be possible to cancel
another requestAnimationFrame callback scheduled to run in the same frame by
using cancelAnimationFrame.
See issue:
https://github.com/whatwg/html/issues/4359
Differential Revision: https://phabricator.services.mozilla.com/D20974
--HG--
extra : rebase_source : ff3c69a82f0ef61f562edd1610017a17c8f26276
In the next patch in this series we want to compare the handle of frame
callbacks we are about to run, with a set of canceled handles stored on the
document. This patch makes us pass the handles along with the callbacks so we
can do that.
Incidentally doing this allows us to just swap array elements when building up
the refresh driver's set of callbacks to run. That is hopefully a little more
efficient than running the implicit conversion operator on each item and then
appending to an array.
Differential Revision: https://phabricator.services.mozilla.com/D20973
--HG--
extra : rebase_source : 4786ffedf33051298c9593a588a6e8ce70cabf04
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The event rate throttling mechanism is modelled on the logic for "scroll" events
in nsGfxScrollFrame.cpp.
That is
1. When a request to fire an event is posted to the VisualViewport, we create a
new runnable for this and register it with the RefreshDriver. If we already
have a pending runnable, calling VisualViewport->Post...Event() becomes a
no-op.
2. When the RefreshDriver is ready, it executes the runnable, which in turn
fires the actual event and then cleans itself up.
To keep this patch manageable, we simply fire a scroll event every time the
stored visual viewport offset is changed. Because we are storing the absolute
offset of the viewport relative to the page, this behaviour doesn't match the
spec, which demands that scroll events are fired only when the relative offset
between visual and layout viewport changes. We'll fix this up in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D14043
--HG--
extra : moz-landing-system : lando
In each file touched by this commit, there were no mentions of nsAutoPtr
besides the #include.
I verified that the folder layout/base still builds successfully in
non-unified mode after this patch, too. So, none of these files are secretly
using nsAutoPtr and depending on some other .cpp file to provide the header.
Differential Revision: https://phabricator.services.mozilla.com/D12993
--HG--
extra : moz-landing-system : lando
1: Correct the Performance API 'NowUnclamped' to obtain a non-Fuzzed Timestamp
2: Do not compare fuzzed and non-fuzzed timestamps in a Refresh Driver assert,
since this happens so early on that we will eventually compare them and
asserting would be bad.
mTimerAdjustmentObservers is a nsTObserverArray which is infallible,
so no need to check the return value from AppendElement
(which a later patch in this series will remove).
nsRefreshDriver::ObserverArray is a nsTObserverArray which is
infallible, so no need to check the return value from AppendElement
(which a later patch in this series will remove).
The mechanism was added in bug 1168705 for fullscreen, and is only used
for this since then. The spec now has a specific step for this in the
event loop, so specialize this mechanism to match the spec closer.
This patch also changes the caller type of the fullscreenchange event
from non-system to system (via using DispatchTrustedEvent rather than
EventTarget::DispatchEvent(Event&)).
Differential Revision: https://phabricator.services.mozilla.com/D5235
--HG--
extra : source : 179f5fbd9db08518804b613f5e3fefa659c1e0a2
Some methods were not overrides and were never overridden, so they could simply
be non-virtual.
Others were overrides but were not overridden, so they could benefit from being
final to hopefully lead to devirtualized calls.
Though some of these are not strictly necessary because they are inside 'final'
classes, I think they're worth adding anyway, because:
- The 'final' keyword becomes more obvious when looking at methods without the
wider context in sight (e.g., in reviews or searchfox).
- If one day any of these classes becomes non-final, it would keep the final
attribute on these methods by default, and force the programmer to explicitly
reflect before removing 'final' from the methods that need to be overridden.
Depends on D5020
Differential Revision: https://phabricator.services.mozilla.com/D5021
--HG--
extra : moz-landing-system : lando
Before this patch, there is a race condition that the refresh driver updates
the most recent refresh time but animations corresponding to the refresh driver
don't update their internal state, that causes the inconsistency that such
animations are regarded as finished on the most recent time whereas their
internal states represent the animations are still in active. This is the one
of the cause of bug 1466010, i.e. the display item corresponding to the
animation is going to be rebuilt without calling MarkNeedsDisplayItemRebuild.
MozReview-Commit-ID: 9adzDV9E3ka
--HG--
extra : rebase_source : 7120e9f462309d1c4efe995ef64aeead9e29ff8f
