Enable picture caching for scroll bars and UI content
Categories
(Core :: Graphics: WebRender, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: gw, Assigned: gw)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Comment 3•5 years ago
|
||
Backed out changeset 4f126cfd8012 (bug 1584439) for causing wrench bustage
backout: https://hg.mozilla.org/integration/autoland/rev/af4f4ed1a70ce59288c24131244f6a420fb86b99
Assignee | ||
Comment 4•5 years ago
|
||
I've updated the fuzziness annotations for those tests on pixel2, thanks!
Comment 6•5 years ago
|
||
Backed out changeset 3eba60b905c0 (bug 1584439) for causing wrench bustages CLOSED TREE
Backout revision https://hg.mozilla.org/integration/autoland/rev/d958fe844b16815800d7c5a97b05f1849a42f7e8
Failuire logs https://treeherder.mozilla.org/logviewer.html#?job_id=269198042&repo=autoland
Glen can you please take a look?
Assignee | ||
Comment 7•5 years ago
|
||
Hmm, there doesn't seem to be anything obviously wrong in the log files - I wonder if it's crashing but not including any crash information in the log output. Can you see anything in the logs that looks like an application error or crash?
Otherwise, I'll try to add some extra logging information and debug on try and/or a local android build tomorrow.
Assignee | ||
Comment 8•5 years ago
|
||
It does look like it stops running before all the reftests complete, since the output finishes earlier than I'd expect. But then it doesn't seem to include any crash details, and just seems to continue on with the script.
Assignee | ||
Comment 9•5 years ago
|
||
I ran this locally on a pixel2 device.
I found that there was one more test that was failing due to fuzziness. The output is being truncated on the try server for some reason, which is why I couldn't see a failure.
I've updated the fuzziness, and confirmed that they all pass on my pixel2 device. I've kicked off another try run [1] to be safe, then this should hopefully be ready to land again.
[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=fbe2ecef8e9d808d585e06c35e5370d15e52a7da
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
bugherder |
Comment 12•5 years ago
|
||
Seems to have caused bug 1585898.
Description
•