Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
This patch adds plumbing to keep track of why we request frames to be rendered.
This information is then displayed in gecko profile markers on the renderer thread as well as in profiler HUD counters (See "Render reasons" in profiler.rs).
Differential Revision: https://phabricator.services.mozilla.com/D127274
This lets us remove the last explicit 'delete' invocation from the /view
subdirectory. Hooray!
As part of this change, I'm also updating the getter for this member-var to
return a reference instead of a pointer, since it's infallible.
Differential Revision: https://phabricator.services.mozilla.com/D127187
This removes an explicit 'delete', by letting the StaticAutoPtr type handle the
deletion for us automatically and atomically when we clear its value.
Benefits/justification:
* This reduces the potential for double-free bugs.
* This matches existing patterns elsewhere in our code
(search for e.g. "StaticAutoPtr<nsTArray")
* This reduces (by 1) the number of explicit `delete` calls that we need to
consider, when auditing the codebase for potential memory safety issues.
Differential Revision: https://phabricator.services.mozilla.com/D127185
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch is just a refactoring which shouldn't change behavior.
Before this patch, mRootViewManager is a bit of an odd hybrid in terms of its
ownership semantics. If it's pointing to `this`, then it's not an owning
reference (i.e. we don't AddRef or Release it), vs. if it's pointing to some
other instance, then it *is* an owning reference (i.e. we *do* AddRef and
Release it).
After this patch, we change things such that it's unconditionally an owning
reference, with a null value having special meaning.
In particular:
(a) Now, we'll store it in a RefPtr and let that manage the reference counting.
(b) Now, we'll never explicitly assign it to 'this'; instead, we set it to null
and we interpret a null value as an indication that 'this' is the root.
Fortunately, this variable doesn't have many direct usages, so this slight
change in meaning/invariatnts doesn't require very much code to be updated.
This variable is mostly used via the infallible RootViewManager() getter. This
patch updates that getter in accordance with the new contract, and the callers
don't need to worry about this change.
Differential Revision: https://phabricator.services.mozilla.com/D127178
This lets us remove the last explicit 'delete' invocation from the /view
subdirectory. Hooray!
As part of this change, I updated the getter for this member-var to return a
"const UniquePtr&" instead of a raw pointer, per this recommendation in
UniquePtr.h:
https://searchfox.org/mozilla-central/rev/7539ad54ddc720a0553efd07ca681b9a409f9887/mfbt/UniquePtr.h#171-173
(Fortunately the getter only has two callers, so they were easy to fix.)
I also changed the name of the getter to drop "Get", per our convention that
getters can hint at infallibility by the absence of "Get".
Depends on D127185
Differential Revision: https://phabricator.services.mozilla.com/D127187
This removes an explicit 'delete', by letting the StaticAutoPtr type handle the
deletion for us automatically and atomically when we clear its value.
Benefits/justification:
* This reduces the potential for double-free bugs.
* This matches existing patterns elsewhere in our code
(search for e.g. "StaticAutoPtr<nsTArray")
* This reduces (by 1) the number of explicit `delete` calls that we need to
consider, when auditing the codebase for potential memory safety issues.
Depends on D127180
Differential Revision: https://phabricator.services.mozilla.com/D127185
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch is just a refactoring which shouldn't change behavior.
Before this patch, mRootViewManager is a bit of an odd hybrid in terms of its
ownership semantics. If it's pointing to `this`, then it's not an owning
reference (i.e. we don't AddRef or Release it), vs. if it's pointing to some
other instance, then it *is* an owning reference (i.e. we *do* AddRef and
Release it).
After this patch, we change things such that it's unconditionally an owning
reference, with a null value having special meaning.
In particular:
(a) Now, we'll store it in a RefPtr and let that manage the reference counting.
(b) Now, we'll never explicitly assign it to 'this'; instead, we set it to null
and we interpret a null value as an indication that 'this' is the root.
Fortunately, this variable doesn't have many direct usages, so this slight
change in meaning/invariatnts doesn't require very much code to be updated.
This variable is mostly used via the infallible RootViewManager() getter. This
patch updates that getter in accordance with the new contract, and the callers
don't need to worry about this change.
Differential Revision: https://phabricator.services.mozilla.com/D127178
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
mHasScheduleFlush is meant to track mViewManagerFlushIsPending except mViewManagerFlushIsPending gets set to false just before we call ProcessPendingUpdates, whereas mHasScheduleFlush is set to false just after we call ProcessPendingUpdates.
There are a couple places where mViewManagerFlushIsPending gets set to false that don't clear mHasScheduleFlush though. This leaves mHasScheduleFlush true until we get another paint that changed something. This causes this code
https://searchfox.org/mozilla-central/rev/3a0a8e2762821c6afc1d235b3eb3dde63ad3b01a/layout/painting/nsDisplayList.cpp#3058
in nsDisplayList::PaintRoot to always notify of invalidation (with webrender). This in turn causes a loop in the reftest harness: notify invalidation -> mozafterpaint -> update canvas -> paint -> notify invalidation.
This code changed a bunch until settling on the current design in bug 1404091.
Differential Revision: https://phabricator.services.mozilla.com/D61738
--HG--
extra : moz-landing-system : lando
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And also this patch moves some related methods which use the inline methods
and member variables used only by them.
Differential Revision: https://phabricator.services.mozilla.com/D29201
--HG--
rename : layout/base/nsIPresShellInlines.h => layout/base/PresShellInlines.h
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
This patch makes `nsViewManager::GetPresShell()` and
`nsIWidgetListener::GetPresShell()` (overridden by `nsView` and
`nsWebShellWindow::WidgetListenerDelegate`) return `mozilla::PresShell*`.
Additionally, makes `nsWebShellWindow::GetPresShell()` also return
`mozilla::PresShell()`.
Differential Revision: https://phabricator.services.mozilla.com/D26454
--HG--
extra : moz-landing-system : lando
When preceding mouse event is handled, that may cause changing style of the
target. Therefore, when an eMouseDown or eMouseUp event is handled, handlers
require the latest layout. Currently, nsViewManager::DispatchEvent() tries
to guarantee that with calling nsIPresShell::FlushPendingNotifications()
with FlushType::Layout. However, this just flushes the pending layout in
the PresShell associated with the nsViewManager instance. I.e., if the
target is in a child PresShell, its layout hasn't been flushed.
This patch makes PresShell::EventHandler::HandleEvent() flush pending
notifications at first of handling events using coordinates (only when
eMouseDown or eMouseUp, though). Then, when it realizes that the event
should be handled in a child PresShell, makes it flush its pending
notifications and then, recompute event target with the latest layout if
the layout is actually changed.
Differential Revision: https://phabricator.services.mozilla.com/D13720
--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.
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 66f8ee003d2f70111f4cff16d6e2d906ef4bf10b
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : fb1ff20aeebb7ac494227e62ba2101039578808c
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 34fb2ca94151403a6d7ffd5a8b840f00a8bb4afb
Botond Ballo
Emilio Cobos Álvarez
Cristian Tuns
Jeff Muizelaar
Nicolas Silva
Daniel Holbert
Sandor Molnar
Matt Woodrow
Csoregi Natalia
Gerald Squelart
Mats Palmgren
Masayuki Nakano
Eric Rahm
Timothy Nikkel
Sylvestre Ledru
Jean-Yves Avenard
Gurzau Raul
Markus Stange
Noemi Erli
Chris Peterson