Differential Revision: https://phabricator.services.mozilla.com/D124547

Bug 1729117 - Copy relevant comments from LayerMetricsWrapper.h to WebRenderScrollDataWrapper.h. r=hiro

I also took the opportunity to update the main comment describing
the wrapper to refer to ScrollMetadata rather than FrameMetrics.

Differential Revision: https://phabricator.services.mozilla.com/D124546

Differential Revision: https://phabricator.services.mozilla.com/D124545

These APIs were only used by AsyncCompositionManager.

Differential Revision: https://phabricator.services.mozilla.com/D124544

Differential Revision: https://phabricator.services.mozilla.com/D124543

Backed out changeset a3f6c7094ec4 (bug 1728993)
Backed out changeset c8800504488b (bug 1728993)
Backed out changeset c045e3ee9650 (bug 1728993)

Now that WebRender is on in all configurations, this flag only
needs to be set to 'Internal' in 'LayersOnly' gtest fixtures
(which are also renamed in this patch to 'Internal').

Differential Revision: https://phabricator.services.mozilla.com/D124542

Also add a |WebRenderLayerScrollData* root| member for convenience.

Differential Revision: https://phabricator.services.mozilla.com/D124541

Differential Revision: https://phabricator.services.mozilla.com/D124533

Differential Revision: https://phabricator.services.mozilla.com/D124532

Differential Revision: https://phabricator.services.mozilla.com/D124531

Differential Revision: https://phabricator.services.mozilla.com/D124530

Differential Revision: https://phabricator.services.mozilla.com/D124529

Differential Revision: https://phabricator.services.mozilla.com/D124528

Differential Revision: https://phabricator.services.mozilla.com/D124527

Differential Revision: https://phabricator.services.mozilla.com/D124526

Differential Revision: https://phabricator.services.mozilla.com/D124525

Differential Revision: https://phabricator.services.mozilla.com/D124524

Bug 1593381 - Provide a minimal implementation of WebRenderScrollDataWrapper::GetClipRect() which is sufficient to get the tests to pass. r=hiro

Differential Revision: https://phabricator.services.mozilla.com/D124523

Differential Revision: https://phabricator.services.mozilla.com/D124522

Use this ability to set event regions corresponding to the visible region
in TestWRScrollData::Create().

Differential Revision: https://phabricator.services.mozilla.com/D124521

Differential Revision: https://phabricator.services.mozilla.com/D124520

Part of this test had to be removed because it performs an operation,
"change a FrameMetrics which is shared with another Layer", which
the WR data structures do not support, and which does not need
test coverage (since production code cannot do it either).

Differential Revision: https://phabricator.services.mozilla.com/D124297

Differential Revision: https://phabricator.services.mozilla.com/D124296

Bug 1593381 - Port CreateSimpleScrollingLayer(), and the tests that use it, to use WR inputs. r=hiro

Differential Revision: https://phabricator.services.mozilla.com/D124294

For now, the class also retains the ability to use Layer inputs.
This allows porting its subclasses incrementally.

Differential Revision: https://phabricator.services.mozilla.com/D124292

Differential Revision: https://phabricator.services.mozilla.com/D124291

Bug 1593381 - Introduce a more generic mechanism for APZ test code to access private members of APZ types. r=hiro

Differential Revision: https://phabricator.services.mozilla.com/D124290

Differential Revision: https://phabricator.services.mozilla.com/D124289

Bug 1593381 - Extend TestWRScrollData::Create() with parameters to set visible regions and transforms. r=hiro

Differential Revision: https://phabricator.services.mozilla.com/D124288

The replacement TestWRScrollData::Create(), which creates a
TestWRScrollData object, which extends WebRenderScrollData with
some functions useful for tests.

The patch also ports the existing tests of LayerMetricsWrapper
to test WebRenderScrollDataWrapper instead and exercise the
new function.

Differential Revision: https://phabricator.services.mozilla.com/D124002

Bug 1729680. Make mCumulativeResolution on FrameMetrics include css transform scale with webrender. r=botond

With non-wr cumulative resolution contained the presshell resolution, css transform scales, and so called extra resolution. The extra resolution came about from FrameLayerBuilder code called ChooseScale that sometimes chose to render at a larger resolution so that we didn't have to re-render on every frame for animating scales for example.

Bug 1485834 is responsible for the current code and it looks it was just getting zooming to work at all on android with webrender. It put the presshell resolution into mCumulativeResolution. This would make zooming work as before this mCumulativeResolution would be 1. This is because mCumulativeResolution came from the ContainerParameters, which are an implementation detail of non-wr that wr didn't have. So it looks like bug 1485834 just used what was handy (the presshell resolution) to get zooming to work.

Making this use GetTransformToAncestorScale means that we are the same as non-wr except for the extra resolution.

I'm not sure that non-wr should have used the extra resolution, I think it would have been better off using GetTransformToAncestorScale as well.

Using the scale from GetTransformToAncestorScale is what several other places do already: CalculateBasicFrameMetrics, and the code to compute our display port rect from the margins data, so this should be more consistent.

More generally speaking, I think that other than the notable exceptions below, mCumulativeResolution only needs to be set to the presshell resolution, and it is okay to include the css transform scale or extra resolution as long as we do apply and un-apply it consistently. Most places that use mCumulativeResolution multiply it in one place and then divide it in another.

The main exception to that is the display port size in the following places:

1. layer pixels computed using mCumulativeResolution are compared against prefs that are in layer pixels in ExpandDisplayPortToDangerZone

https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/apz/src/AsyncPanZoomController.cpp#4072

2. GetDisplayportAlignmentMultiplier uses layer pixels computed using mCumulativeResolution to determine alignment

https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/apz/src/AsyncPanZoomController.cpp#3969

3. CalculatePendingDisplayPort sets the final displayport margins in screen pixels computed using mCumulativeResolution

https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/apz/src/AsyncPanZoomController.cpp#4171

4. GetDisplayPortFromMarginsData computes the actual displayport rect we use for painting using GetTransformToAncestorScale

https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/layout/base/DisplayPortUtils.cpp#296

Ideally this should match how we calculate the margins in CalculatePendingDisplayPort.

One will note that after this patch extra resolution is always 1 (I plan to remove it in a followup), one might wonder if that is true with webrender. It is true that webrender still has ChooseScale

https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/wr/StackingContextHelper.cpp#46

and it uses when it encounters content that it cannot natively render so it is rasterized or recorded in the content process. So content can get rasterized or recorded with extra resolution, however it doesn't make it to the wr side in a structured fashion. The items in question are sent to wr as "images" (blob images) with a rect that is equal to their layout rect, without any transforms, resolution, or extra resolution applied. The "images" themselves do contain the extra resolution but they would be drawn using that non-transformed layout rect, and in this case since they have a transform, that transform would be sent to wr on the stacking context pushed for that transform and then that transform would be applied. Wr would not except apz to know about this extra resolution and would not expect values it gets from apz to include this extra resolution.

Now inside wr it could also do something similar where it renders at a resolution that differs from the presshell resolution + css transform scale, but that too would have to be completely internal to wr and it could not expect anyone outside of wr to know about.

The other thing that simplifies this is that the only scrollframe that can have resolution (root content doc root scroll frame) cannot also be transformed. This means that when we are actually managing the zoom (on the rcd-rsf) we never have a css transform scale. And for subframes, other than the displayport sizing, we mostly just multiply and divide by cumulative resolution so it's specific value isn't that important.

Differential Revision: https://phabricator.services.mozilla.com/D124905

This also remove layers.bufferrotation.enabled pref.

Differential Revision: https://phabricator.services.mozilla.com/D125022

Differential Revision: https://phabricator.services.mozilla.com/D125011

When we position noautohide popup we can't use xdg_positioner as the popup
is rendered aside popup hierarchy and can be closed by user interaction only.

Try to keep the popup on screen by just moving it in scope of
it's parent window.

Differential Revision: https://phabricator.services.mozilla.com/D124909

This adds a test that goes through all combinations of a number of important features, and verifies that the JSON output looks valid.

Differential Revision: https://phabricator.services.mozilla.com/D124739

All profiles submitted to `JSONOutputCheck` are now checked for valid-looking samples, as in:
- Samples should point into the stackTable.
- stackTable entries should point to the caller in the same stackTable (or null for the root frame).
- stackTable entries should also point into the frameTable.
- frameTable entries should point into the stringTable for the "location".

Differential Revision: https://phabricator.services.mozilla.com/D124738

A scenario for a thread may be that the first entry has an empty sample (usually if stack-sampling is turned off) and no running times (first-ever sample, or "cpu" is off), so it's not output, and there is no corresponding stack table entry.
Then there may be a "same sample" entry.
- If there are no running times, nothing should be output.
- If there are running times, an empty stack should be output, but for that we need to ensure that the root frame is present in the stack table entry, because that represents an empty stack.

Differential Revision: https://phabricator.services.mozilla.com/D124612

Differential Revision: https://phabricator.services.mozilla.com/D125005

Bug 1729816 - part 2: Remove unused CompositableHost::BumpFlashCounter(). r=gfx-reviewers,mattwoodrow

Differential Revision: https://phabricator.services.mozilla.com/D125004