PS contains some state that is always valid, and some state that is only valid
when the profiler is active. This patch does the following.
- Splits PS into two parts for the two kinds of state: CorePS and ActivePS.
- Moves gPS (now split in two) into CorePS and ActivePS, as static instances,
to improve encapsulation. This required changing all the state getters and
setters into static methods.
- Existence tests for CorePS and ActivePS are now done via the Exists()
methods.
Advantages of this change:
- It's now clear which parts of the global state (most of it!) are valid only
when the profiler is active, and we don't have to invalidate those parts with
zero/null/false when the profiler stops.
- Better OOP: more use of constructors and destructors, and more |const| to
indicate what state is immutable.
- With the old code there were some places where the order of things required
care, but with the new code it's not possible to get the order wrong.
--HG--
extra : rebase_source : dba177acb41e4dc2103ace2212ab5ae1f7b418ce
This fixes a JS exception that gets thrown when one tries to capture a profile
in this case.
--HG--
extra : rebase_source : 46f6eeed3c17086b0b6c35b26f3c9e4841dd6cff
This matches the rest of the context menu and is better for unit tests.
MozReview-Commit-ID: 509HH4wnClN
--HG--
extra : rebase_source : 61456ee75f75baefd38fd9dd53e9cce9b7e3fefa
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 90f79b6f4a2d8d925dd20eb0bf6ab96262c227d5
The JS engine has a notion of ZoneGroup that we plan to use as
the unit of threading for Quantum DOM. We want to create one
ZoneGroup per TabGroup so that the two concepts are 1:1.
MozReview-Commit-ID: IDmGGRZBNpQ
When APZ traverses a tree using LayerMetricsWrapper, the layer tree
already has its RefLayers connected because of the in-scope
AutoResolveRefLayers. When traversing using the
WebRenderScrollDataWrapper though, this is not the case, and we need to
explicitly jump from one layer tree to another during the walk.
Thankfully we don't require upwards traversal in the tree or this would
be much more complicated.
MozReview-Commit-ID: 8gbvUlzghLx
This puts all the other things that APZ needs into the
WebRenderScrollData object. The main exception is the scroll clip - I'm
not totally sure how that will be handled yet, so for now we just return
no clip from WebRenderScrollDataWrapper.
MozReview-Commit-ID: 1IhGhSFiPYi
This mainly implements the GetLastChild and GetPreviousSibling functions
in the WebRenderScrollDataWrapper, and adds helper functions that are
needed to make that possible. This allows the WebRenderScrollDataWrapper
to simulate a full "LayerMetrics" tree using the information in the
underlying WebRenderScrollData object.
MozReview-Commit-ID: K82Ud2gAo8K
This adds the WebRenderScrollDataWrapper class which is
template-compatible with LayerMetricsWrapper. While the
LayerMetricsWrapper operates on an underlying layer tree, the
WebRenderScrollDataWrapper will simulate a layer tree based on an
underlying WebRenderScrollData object. The class is stubbed out here,
functions will be implemented in subsequent patches.
MozReview-Commit-ID: 9exnFRI6tOW
This further abstracts away the direct dependence on particular layer
types. This is needed in particular for the APZCTreeManager call site
since it will need to operate on non-layer-tree data which is hard if it
relies specifically on RefLayer.
MozReview-Commit-ID: zbK3oTNHJc
Currently the public UpdateHitTestingTree function takes a Layer* which
assumes there is a layer tree to traverse. However, with WebRender, that
is not the case. This patch has two conceptual changes.
The first change is to extract the innards of UpdateHitTestingTree to take
a LayerMetricsWrapper instead of a Layer* and traverse the layer tree
using that. This was already mostly happening but this makes the
Layer*/LayerMetricsWrapper boundary a little more explicit.
The second change is to make the extracted helper function templated, so
it accepts anything that is template-compatible with
LayerMetricsWrapper. I chose to use a template rather inheritance to
avoid the performance hit of virtual functions, since this code runs
relatively often.
This paves the way for adding a different kind of tree-traversal object
instead of the LayerMetricsWrapper while reusing the same logic to build
the hit-testing tree and APZC nodes.
MozReview-Commit-ID: 6SmnX6Bn2QV
This adds a WebRenderScrollData class (which contains a list of
WebRenderLayerScrollData objects, among other things), and adds it to
the DPEnd/DPSyncEnd messages sent across PWebRenderBridge. These classes are
skeletons for now (more stuff will be added to them in future patches).
MozReview-Commit-ID: 9duxwlUpdu7
The method Context.getDrawable was introduced in API 21. To be
compatible with Kitkat, should use Resources.getDrawable instead.
MozReview-Commit-ID: 1ZajYWPTVj0
--HG--
extra : rebase_source : d9aa89d3cae5040b861cc6c07f2a2461fab4ce82
To clean up TextEditRules, I would like to replace nsIDOMNode with nsINode and nsIContent in TextEditRules.
GetTopEnclosingPre is unused define, so I also remove it.
MozReview-Commit-ID: 6LraexH5t4m
--HG--
extra : rebase_source : 1037dcfd949d544282dc30360bd43773f21fd929