Scrolling a zoomed in https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg uses 100% CPU (restrict masks to tile bounds)
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
People
(Reporter: mayankleoboy1, Assigned: jrmuizel)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
(Keywords: nightly-community, regression)
Attachments
(4 files, 2 obsolete files)
|
(deleted),
patch
|
Details | Diff | Splinter Review | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 Build ID: 20180928220433 Steps to reproduce: enable WR open https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg zoom in the SVG to 400%-500% Scroll up and down, or sideways Actual results: after a little scroll, the SVG uses 100% CPU http://bit.ly/2IoqNC3f the gaps in the profile are when the SVG is using 100% CPU Expected results: not so, maybe This could be a dupe of other zoom+Svg bugs
|
Reporter | |
Comment 1•6 years ago
|
||
Heres a non-WR profile. The CPU usage never went over 40%. The red regions in profile relate to checkerboarding, and not stutter. The WR version had equal checkerboarding, FWIW. http://bit.ly/2In9y3P
|
||
Updated•6 years ago
|
|
||
Comment 3•6 years ago
|
||
This is quite a bit worse with zoom than without, so I wouldn't mark it as a dupe of bug 1447778, which has just been determined to be "not bad enough to block anymore".
|
|
||
Comment 4•6 years ago
|
||
| checkerboarding | ||
With 200% zoom on a GTX 1060 it's as bad as without zoom on Mac, so I perceived it as the same general topic.
|
|
Reporter | |
Comment 6•6 years ago
|
||
Heres the WR profile : http://bit.ly/2Ip4bB9 AFAIK, nothing stands out in the profile. Is it doing lots of texture upload?
|
|
||
Comment 7•6 years ago
|
||
It's spending too much time on painting (the activity in the WRWorker threads).
|
|
Reporter | |
Comment 8•6 years ago
|
||
this hasnt improed by the WR SVG filter work : https://perfht.ml/2z0PzED
|
||
Updated•6 years ago
|
|
|
Reporter | |
Comment 9•6 years ago
|
||
This appears to have regressed a bit. I zoomed to 1100%, then quickly scrolled down. The CPU use went to 100%, and stayed there for a long time (longer then I remember from last time I posted the profile in comment #8) All the time appears to be spent in filters. Maybe it the filter multiplication part got slower, or maybe its doing that for a larger area? Profile: https://perfht.ml/2K7Sq39
|
|
Reporter | |
Comment 10•6 years ago
|
||
Also, it looks like maybe we are too aggressively "freeing" memory while the filter calculation is being done From the windows task manager, the process continuously switched between 1300MB-650MB RAM. Sometimes even going to 2100MB-300MB
|
Assignee | |
Comment 11•6 years ago
|
||
Bug 1480620 could help here. My feeling is we probably don't need to block on this, but it would be nice to do better.
|
|
Assignee | |
Comment 12•6 years ago
|
||
I think the biggest problem left on this page is probably caused by us having filters inside of masks. The masks are not clipped to tile size and so the filters are not clipped either. It should be possible to solve this by using CreateClippedDrawTarget for the masks.
|
|
Assignee | |
Comment 14•6 years ago
|
||
Bug 1429508 was the bug that introduced CreateClippedDrawTarget and serves as an example of what we want to do.
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 16•6 years ago
|
||
This patch seems to speed up drawing by about 4-5x. Even with this patch it looks like we're basically still malloc bound, so I suspect there's still some fishy things going on.
|
|
Assignee | |
Comment 17•6 years ago
|
||
This still fails a bunch of reftests.
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 18•6 years ago
|
||
The reftest failures are pretty bad. I need to think about a better way to fix this.
|
|
Assignee | |
Comment 19•6 years ago
|
||
The problem is that we're not offsetting the clipped snapshots the appropriate amount.
|
|
Assignee | |
Comment 20•6 years ago
|
||
I got this somewhat working today. There's still a memory corruption issue that I'll look at tomorrow.
|
|
Assignee | |
Comment 21•6 years ago
|
||
|
||
Comment 23•6 years ago
|
||
Pushed by jmuizelaar@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/df0f64d6ae61 Handle mask offsets. https://hg.mozilla.org/integration/mozilla-inbound/rev/20d6f233678b Use CreateClippedDrawTarget more. r=mstange
|
||
Comment 24•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/df0f64d6ae61
https://hg.mozilla.org/mozilla-central/rev/20d6f233678b
|
||
Updated•6 years ago
|
|
||
Updated•6 years ago
|
|
||
Comment 25•6 years ago
|
||
Hi, this issue is Verified as fixed on Windows 10 machines in the latest Firefox Nightly 67.0a1 (2019-03-06).
|
|
||
Updated•6 years ago
|
|
|
Assignee | |
Comment 26•6 years ago
|
||
Some of the remaining performance issues here are the malloc contention, the dwrite contention and the invalidation disaster.
|
|
Reporter | |
Comment 27•6 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #26)
Some of the remaining performance issues here are the malloc contention, the
dwrite contention and the invalidation disaster.
any bug for the invalidation disaster?
|
|
Assignee | |
Comment 29•6 years ago
|
||
Description
•