RenderTask::new_mask crash on https://www.magicleap.com/creator
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox64 | --- | disabled |
| firefox65 | --- | disabled |
| firefox66 | --- | verified |
People
(Reporter: jrmuizel, Assigned: kvark)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(2 files)
No description provided.
|
||
Comment 1•6 years ago
|
||
Load the page in the title and scroll down. This is the crash report I get: https://crash-stats.mozilla.com/report/index/7cfc4f65-8a50-4789-b2a7-69aee0181108
|
|
||
Updated•6 years ago
|
|
Reporter | |
Updated•6 years ago
|
|
|
Reporter | |
Updated•6 years ago
|
|
|
Reporter | |
Updated•6 years ago
|
|
||
Comment 2•5 years ago
|
||
dupe of 1513062 ? latest crash: https://crash-stats.mozilla.com/report/index/92bf58ce-4d37-40b1-aa28-0b6670181213
|
||
Comment 4•5 years ago
|
||
Same crash on https://www.magicleap.com/magic-leap-one. Both have the same regression range.
|
|
||
Comment 5•5 years ago
|
||
Thanks for noticing the dupe :)
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
I've been investigating this assert and it's related to perspective applied to an image with scaling. Reduced testcase https://djg.github.io/wr_testcase/magickit.html It might required clicking in the frame to trigger the assert. It doesn't always happen immediately. I don't understand the behavior of elements with perspective applied and how pictures interact, but we shouldn't render at 90000x90000 to scale back down to 900x900. :emilio, :mattwoodrow can either of you help?
|
||
Comment 7•5 years ago
•
|
||
The testcase appears to roughly be:
scale(1/50)
clip(rounded-rect)
scale(50)
image
With the addition of perspective, to make the transforms more difficult.
The presence of the perspective means that it's hard to combine the two transforms, as we'd also have to transform the rounded rect and turn it into an arbitrary mask.
I guess that's one possible option, otherwise we probably just need to do the intermediate surface at a lower resolution (scale down to fit within a reasonable size).
The test also has opacity, so the path that hits the assert in WR is setting up the processing of the PictureCompositeMode::Filter(Opacity(..)) at https://github.com/servo/webrender/blob/1b226534099a24c741e9827c4612eee1ec12d4ee/webrender/src/picture.rs#L2522.
It would be better that someone who understands picture caching to implement the correct fix for this, instead of me, so I'm unassigning myself so it can be picked up by another.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 9•5 years ago
|
||
|
|
Assignee | |
Comment 10•5 years ago
|
||
There is a combination of factors in play here:
- a filter forces some compositor mode, which makes WR want to produce a surface for the stacking context
- a perspective transformation makes WR to choose the local space for rasterization
- a very large clip mask as an example of a render task
Produced test case (included in the crashtests with the PR):
<style>
body {
background-color: limegreen;
}
.A {
transform: scale(0.01) perspective(1000px);
transform-origin: 0% 0%;
filter: grayscale(40%);
}
.B {
background-color: black;
width: 10000px;
height: 5000px;
border-radius: 2000px;
}
</style>
<body>
<div class="A">
<div class = "B"/>
</div>
</body>
|
||
Comment 11•5 years ago
|
||
I got this issue today.
[Reproduce Steps]
- Restart Firefox 65.0b10
- Go to http://hitoki.info/
- Then Firefox 65.0b10 will be crashed sometimes.
|
|
||
Updated•5 years ago
|
|
||
Comment 13•5 years ago
|
||
Pushed by dmalyshau@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/58ebeaf27cf6 WR: Don't establish a raster root in pictures with sufficiently large local bounds r=gw
|
||
Comment 14•5 years ago
|
||
Backed out for wrench bustages.
Push link: https://hg.mozilla.org/integration/autoland/rev/58ebeaf27cf6c123bfd8de1f29c4034ad42435d5
Backout link: https://hg.mozilla.org/integration/autoland/rev/bb6af9b92cdf9aa3becad03e149ee1c265805452
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=221786737&repo=autoland&lineNumber=2834
|
|
Assignee | |
Comment 15•5 years ago
|
||
re-open of D16335, which got backed out due to Wrench test failing. The test was failing because of different AA on a plane-splitting case, which isn't guaranteed anyway. This revision updates the test.
|
|
||
Comment 16•5 years ago
|
||
Pushed by dmalyshau@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/97ae7728e243 WR: Don't establish a raster root in pictures with sufficiently large local bounds (take 2) r=jrmuizel
|
|
Assignee | |
Comment 17•5 years ago
|
||
Re-landing now with the Wrench test adjusted: it's purpose is to check the ordering of planes in preserve-3d context. We don't guarantee AA there, so the change in result is acceptable.
|
||
Comment 18•5 years ago
|
||
| bugherder | ||
|
|
||
Comment 19•5 years ago
|
||
bug 1515932 was not a dupe. Removing signature.
|
||
Comment 20•5 years ago
|
||
I have managed to crash Fx 65.0a1 buildID: 20181108220756 using the page in the title only on macOS 10.14. On Ubuntu 16.04 Fx only crashed with the link from comment 6. On Windows Fx didn't crash at all, 'best' result being the window becoming unresponsive for 2-3 seconds then returning to normal.
The issue is verified fixed using Fx 66.0b14 on macOS 10.14, Ubuntu 16.04 and Windows 10. The issues mentioned above no longer occur on the latest beta with gfx.webrender.all set to true.
Description
•