Closed Bug 1495170 Opened 7 years ago Closed 6 years ago

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)

Product:
Core
Component:
Graphics: WebRender
Platform:
Unspecified
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla67
Tracking Flags:
Tracking Status
firefox64 --- disabled
firefox65 --- disabled
firefox66 --- disabled
firefox67 --- verified

People

(Reporter: mayankleoboy1, Assigned: jrmuizel)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Keywords: nightly-community, regression)

Attachments

(4 files, 2 obsolete files)

Somewhat working version
8.15 KB, patch
Details | Diff | Splinter Review
Bug 1495170. Handle mask offsets.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1495170. Use CreateClippedDrawTarget more.
47 bytes, text/x-phabricator-request
Details | Review
A patch to reduce the contention
5.79 KB, 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
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
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
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".
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.
Blocks: stage-wr-trains, wr-perf
URL: https://static.mozilla.com/moco/en-US...
Status: RESOLVED → REOPENED
status-firefox64: --- → affected
Keywords: nightly-community
OS: Unspecified → All
Priority: -- → P3
Resolution: DUPLICATE → ---
See Also: → 1447778
If performance would be improved, it might fix bug 1494164 as well.
Heres the WR profile : http://bit.ly/2Ip4bB9 AFAIK, nothing stands out in the profile. Is it doing lots of texture upload?
It's spending too much time on painting (the activity in the WRWorker threads).
this hasnt improed by the WR SVG filter work : https://perfht.ml/2z0PzED
Priority: P3 → P2
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
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
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.
Priority: P2 → P4

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.

Summary: Scrolling a zoomed in SVG uses 100% CPU → Scrolling a zoomed in SVG uses 100% CPU (restrict masks to tile bounds)

Bug 1429508 was the bug that introduced CreateClippedDrawTarget and serves as an example of what we want to do.

Summary: Scrolling a zoomed in SVG uses 100% CPU (restrict masks to tile bounds) → 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)
Assignee: nobody → jmuizelaar
Attached patch Use CreateClippedDrawTarget (obsolete) — — Splinter Review

An untested patch that I think should help.

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.

Attachment #9045121 - Attachment is obsolete: true

This still fails a bunch of reftests.

Attachment #9045131 - Attachment is obsolete: true
Blocks: wr-67
No longer blocks: stage-wr-trains
Priority: P4 → P2
Blocks: 1477372

The reftest failures are pretty bad. I need to think about a better way to fix this.

The problem is that we're not offsetting the clipped snapshots the appropriate amount.

I got this somewhat working today. There's still a memory corruption issue that I'll look at tomorrow.

Depends on: 1531532

Depends on D21749

https://hg.mozilla.org/mozilla-central/rev/df0f64d6ae61
https://hg.mozilla.org/mozilla-central/rev/20d6f233678b

Status: REOPENED → RESOLVED
Closed: 7 years ago → 6 years ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

Hi, this issue is Verified as fixed on Windows 10 machines in the latest Firefox Nightly 67.0a1 (2019-03-06).

Status: RESOLVED → VERIFIED
status-firefox67: fixed → verified

Some of the remaining performance issues here are the malloc contention, the dwrite contention and the invalidation disaster.

Depends on: 1533545
Depends on: 1533546

(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?

Depends on: 1567291
Regressions: 1617708
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: