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)
Comment 1•7 years ago
|
||
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
Comment 2•7 years ago
|
||
Comment 4•7 years ago
|
||
Comment 5•7 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 7•7 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•7 years ago
|
Assignee | ||
Comment 9•7 years ago
|
||
Assignee | ||
Comment 10•7 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•7 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•7 years ago
|
Comment 13•7 years ago
|
||
Comment 14•7 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•7 years ago
|
||
Comment 16•7 years ago
|
||
Assignee | ||
Comment 17•7 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•7 years ago
|
||
bugherder |
Comment 19•6 years ago
|
||
bug 1515932 was not a dupe. Removing signature.
Comment 20•6 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
•