Previously, if we encounter a page where there are no real scroll
roots, WR would attach the picture cache slices to the root reference
frame.

This means that in some cases, no shared clips will be found for the
content slices. This is not currently a performance issue, since the
content slices are fixed and don't scroll. However, future patches
for this bug will only select shared clips that are ancestors of
the picture cache scroll root.

This patch ensures that in these cases, we still select the outermost
defined scroll frame, allowing shared clips to be correctly found
for these pages with a single scroll frame that doesn't scroll.

Instead of selecting any rectangle clips as potential shared clips
for content in a picture cache slice, only select clips that are
positioned by an ancestor spatial node of the picture cache
scroll root.

This ensures we don't incorrectly select rectangle clips on the
primitive as potential shared clips, which will be important in
the follow up patches for this bug.

https://hg.mozilla.org/mozilla-central/rev/f66cec1aee94
https://hg.mozilla.org/mozilla-central/rev/0ea4a897ea2f

This is a rare edge case, but it affects which clips are able to be considered
as shared clips. Fixing this makes the shared clips more likely to be consistent,
which will be important for the follow up patches in this bug. This mostly
only affects Gecko when running with Fission enabled.

This patch changes the picture cache logic to create a new slice
if it finds a primitive with an incompatible set of shared clips.

In testing, I have been unable to find any real world content that
hits this case. There is a single test case in CI that hits this
case, which confirms that a new slice is created correctly. Due
to this, it should have minimal effect on real world browsing.

The benefit of this is that we know the set of shared clips won't
change as we continue to build the scene. The follow up patch to
this can then filter out and remove shared clips from primitives
during scene building, rather than frame building.

== Change summary for alert #26948 (as of Wed, 16 Sep 2020 15:23:49 GMT) ==

Improvements:

5% raptor-tp6-twitter-firefox-cold fcp linux64-shippable-qr opt webrender 213.71 -> 203.67
3% raptor-tp6-yandex-firefox-cold fcp linux64-shippable-qr opt webrender 315.50 -> 306.25
3% raptor-tp6-youtube-firefox-cold fcp linux64-shippable-qr opt webrender 456.21 -> 443.00
3% raptor-tp6-bing-firefox-cold fcp linux64-shippable-qr opt webrender 287.75 -> 279.50
2% raptor-tp6-yahoo-mail-firefox-cold fcp linux64-shippable-qr opt webrender 400.00 -> 391.17

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=26948

This was disabled temporarily to fix a regression. It was resolved
by 1665805, which fixes an unrelated bug in the CoreAnimation
implementation due to coordinate accuracy.

This is no longer useful since we create a separate slice when the
shared_clip config changes. Users who want to prefer subpixel AA
over (significant) performance improvements can enable the config
value `gfx.webrender.quality.force-subpixel-aa-where-possible'.

https://hg.mozilla.org/mozilla-central/rev/c8102686489e
https://hg.mozilla.org/mozilla-central/rev/c90418894bcf

Backed out for wrench failures on text-fixed-slice.yaml

backout: https://hg.mozilla.org/integration/autoland/rev/d4bf04fc963a58831b9a6b220cee493493446eaf

push: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=994c13da52dc80ad8996c059ab052e8b3cf56797&selectedTaskRun=fqXg80bPQyW118q_UMTlBA.0

failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=316444169&repo=autoland&lineNumber=2558

[task 2020-09-23T03:21:48.922Z] REFTEST reftests/text/raster-space-snap.yaml == reftests/text/raster-space-snap-ref.yaml
[task 2020-09-23T03:21:49.205Z] REFTEST reftests/text/text-fixed-slice.yaml == reftests/text/text-fixed-slice-slow.png
[task 2020-09-23T03:21:49.307Z] REFTEST TEST-UNEXPECTED-FAIL | reftests/text/text-fixed-slice.yaml == reftests/text/text-fixed-slice-slow.png | image comparison, max difference: 96, number of differing pixels: 4077 | 4077 num_differences > 0 and <= 255 (allowed 0);

Fixed up the wrench test case that failed. Doing another try push (https://treeherder.mozilla.org/#/jobs?repo=try&revision=dd78efa78c9a5d04c1b0275f41ef8d69060994f9) before re-landing. Thanks!

https://hg.mozilla.org/mozilla-central/rev/80bd0d474dbb

Previously, we relied on walking the built clip-chain for a
stacking context to determine if it needed an intermediate surface
due to presence of a complex clip.

However, future patches in this bug need to delay clip-chain creation
for a primitive until the tile-cache slice for the primitive is
known. This change means we don't rely on the clip-chain early
during push_stacking_context (but should have no functional change).

https://hg.mozilla.org/mozilla-central/rev/329e0bb968c1

Should this bug get closed now, or is there further remaining work? Thanks.

It can be closed - there is still more work to be done here, but we can open other bugs for that at the time.