Bad performance with css "perspective" set
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: sollacea, Assigned: kvark)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Steps to reproduce:
I noticed this with a website I've been working on, that scrolling and performance has been slow and jittery. I thought it was something I did, but upon investigation I found that everything performs fine in the release versions of firefox, and only when I loaded the page in Nightly did it start acting this way.
You can see this effect in action over here:
The site's main banner uses a css perspective of 300px and a perspective-origin set to get the parallax effects. I found that simply removing the perspective declaration (perspective-origin had no effect) that the sluggishness goes away almost completely so I suspect this is caused by some change in the how the browser handles 3d contexts.
Actual results:
The page was really sluggish. Scrolling felt slow, and the banner's parallax effect jittered as if it was done using javascript.
Expected results:
Scrolling and the parallax effect should have been smooth, as-is in Chrome, Edge, and previous (release) versions of Firefox.
|
||
Comment 1•5 years ago
|
||
Hi @sollacea, cannot find the attribute "perspective" / "perspective-origin" or any other described by you. Please add accurate info in order to be tested.
Further, I will add a component, please fell free to change it if isn't the proper one.
Regards,
Liviu
Hi, @Liviu Seplecan.
Here is the relevant portion of the stylesheet from projectvinyl.net (webkit methods removed)
.context-3d {
position:fixed;
top:0;
bottom:0;
left:0;
right:0;
overflow-x:hidden;
overflow-y:auto;
perspective:300px;
perspective-origin:0 100px;
height:100%;
background:inherit
}
This is paired with html that looks like this, where the root element is the 3d-context:
<body>
<div class="context-3d dock-holder">
...
</div>
<div class="floating-player hiding"></div>
<div class="fades"></div>
</body>
I don't believe this is css parsing, btw. This appears to be rendering-specific as otherwise everything appears to be applied correctly.
@Liviu Seplecan Do you need a video of it or something? https://youtu.be/wcNqS0T6egI
|
|
||
Comment 5•5 years ago
|
||
|
|
||
Comment 6•5 years ago
|
||
Hi @sollacea, tks for the video, re-tested in Firefox and Chrome:
- removing the "perspective" attribute => both browsers have the same behavior: no effects will be applied to the #banner.
- having this attribute set => on both browsers the effect will be rendered.
So, I will add a short video to see how is the behavior in my end, cannot see the issue here-> "perspective" on has one behavior / off has another behavior.
Regards,
Liviu
@Liviu Seplecan
Hi, thanks for the video. Just to be clear, the issue I'm describing isn't to do with how the perspective is being applied. The parallax is intended, and removing the attribute will stop it from animating in all browsers, yes.
The issue I'm having is that the entire page itself becomes less responsive when the effect is active, versus when it is not. On previous versions of firefox, and on Chrome I see no performance drop when this effect is active, which leads me to believe it is something that's changed in how the browser handles these rendering conditions.
attribute set => page scrolling stutters
attribute not set => page scrolling is smooth
Okay, I may have found something. I went to about:config and toggled "layers.gpu-process.enabled" to "false" and the problem went away.
I checked on the other browser whether I had the setting any different, but they both had that flag set to "true".
Turning the flag back to "true" and restarting Nightly results in the same problem (performance bottleneck I described above) returning.
|
||
Comment 9•5 years ago
|
||
I can reproduce with webrender enabled. There's a perspective: 300px element (<div class="context-3d dock-holder">) which covers the whole page and is probably causing the badness.
Can you attach your about:support, just to confirm you have WebRender enabled by default?
|
Reporter | |
Comment 10•5 years ago
|
||
Indeed I can (assuming I can figure out how to attach files because I'm not about to post the whole thing in the comment box)
|
|
Reporter | |
Comment 11•5 years ago
|
||
|
|
||
Comment 12•5 years ago
|
||
Yeah, so you do have WR enabled, great :)
Can you confirm that switching to gfx.webrender.force-disabled=true in about:config fixes this perf issue? (Requires a restart).
It does for me.
|
||
Comment 13•5 years ago
|
||
Jeff does this look like it could be similar to bug 1576637 ?
|
||
Comment 14•5 years ago
|
||
We're spending a lot in the clip shader. This looks like it might be similar to our other clipping performance issues.
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 16•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)
Yeah, so you do have WR enabled, great :)
Can you confirm that switching to
gfx.webrender.force-disabled=trueinabout:configfixes this perf issue? (Requires a restart).It does for me.
Hi, hi.
Sorry for the delay. Tried that, and yes, turning that flag on does fix the issue.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 17•5 years ago
|
||
Here is what I found so far:
- the presence of perspective here makes us unable to use the
USE_FAST_PATHflag for the clips - there is a ton of rounded rectangles, roughly covering a 4K by 4K area. Doing this with a slow shader is pretty expensive. Interestingly, these mostly render black, so we should be able to detect this and
a) either not render them at all, or
b) render only unique ones and re-use - there is a lot of transparency in general ~ 200% of the screen estate. All the element backgrounds are transparent?
- we end up batch breaking a lot between TextRun and B_Solid and between B_Image and B_Solid. It's pretty wasteful... we should be able to use a smarter batching policy to avoid that
- the final "composite" pass redraws the screen 3 times! it ends up with only one pixel passing the depth, but I wonder why we draw as much at all here. Perhaps, the logic of picture caching should be smarter and detect the case where a tile doesn't need to be drawn. (cc'ing Glenn)
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 18•5 years ago
|
||
Looked at this again, it feels better now (subjectively), but the issues are still there.
Filed a separate bug 1597319 for fixing (1) and (2).
The (3) is just the fact we recognize a Preserve3D stacking context, and it's expected, to an extent. If the website considers using the "flat" style everywhere, that would save a lot of bandwidth for us.
Technically, we have ways of improving the preserve-3d rendering:
- properly detecting the opaque pieces (filed bug 1597324)
- avoiding separate surfaces if we know at some point that there are no intersections (filed bug 1597326)
However, I'm not sure if this particular website should be taken as a justification to increase the priority on these tasks. We'd need more evidence that this is a problem on popular resources.
|
|
||
Updated•5 years ago
|
Description
•