Construct picture cache slices for scroll roots
Categories
(Core :: Graphics: WebRender, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox72 | --- | fixed |
People
(Reporter: gw, Assigned: gw)
References
Details
Attachments
(1 file)
Assignee | ||
Comment 1•5 years ago
|
||
With this patch, picture cache slices are constructed each time
a new scroll root is established. This reduces rasterization
cost on pages that have large fixed position elements, and pages
that contain multiple scroll roots.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
This patch passes a try run [1], except for tests [2] and [3] on Windows.
In these tests, the content of the test is correct, but the explanatory text is different (it has subpixel AA in one side of the test, and greyscale AA in the other).
In one side of the test, there is an opaque background resulting in subpixel AA. In the other side of the test, the patch results in different slices being created. In this scenario, there isn't an opaque background and thus WR disables subpixel AA for that slice.
There's a few options I can think of:
(1) Disable these tests for WR. Obviously not ideal - but maybe worth doing to land this and see how it goes in nightly? WPT tests don't support fuzziness as far as I know.
(2) Add support to WPT metadata to disable subpixel AA on some tests. I'm not sure if this is desirable or feasible. Also not sure how much work this would involve.
(3) Try harder to detect when we can draw with subpixel AA, and maybe be able to make these tests consistent. I've seen these test failures before, when working on a similar patch (that never landed). I recall that by doing some extra work in WR, I was able to fix some of the tests by tracking extra opaque background areas, but that some of them didn't have any valid opaque region with the selected slicing algorithm. It's unclear to me whether it's worth doing this extra work in WR to get subpixel AA in more cases. Worth spending a couple days investigating?
What are your thoughts on the above, or any other options you can think of?
[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=090f97eedcc9642c6ed48928be478e705a0b1ab0&selectedJob=272512009
[2] https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/PWkZ2DzuRCi_kEjbNCRDtQ/runs/2/artifacts/public/logs/live_backing.log&only_show_unexpected=1
[3] https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/HtgDAvz2RqiKIIlicIO8KQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1
Comment 3•5 years ago
|
||
WPT does support fuzziness, so we could fuzz these. I think that might be the best solution for now. I'm fine with not getting subpixel-aa
Pushed by gwatson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/60e6c61a7f45 Construct picture cache slices for scroll roots. r=kvark
Assignee | ||
Comment 5•5 years ago
|
||
This is quite likely to regress (memory | performance | subpixel AA) on some subset of pages (while hopefully not impacting most sites, and improving performance on a number of known pages with performance issues).
Given that, we want to get it merged early in the nightly cycle to give time to resolve (or at least investigate) any regressions that are reported.
There's some other patches coming in the next couple of weeks that are likely to mitigate any memory regressions.
Assignee | ||
Updated•5 years ago
|
Comment 8•5 years ago
|
||
bugherder |
Comment 9•5 years ago
|
||
== Change summary for alert #23579 (as of Mon, 28 Oct 2019 15:54:04 GMT) ==
Improvements:
11% tscrollx windows10-64-shippable-qr opt e10s stylo 0.91 -> 0.81
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=23579
Description
•