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)

VERIFIED FIXED in Firefox 67

Status

()

defect
P2
normal
VERIFIED FIXED
11 months ago
Last month

People

(Reporter: mayankleoboy1, Assigned: jrmuizel)

Tracking

(Depends on 1 bug, Blocks 1 bug, {nightly-community, regression})

Trunk
mozilla67
Unspecified
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 disabled, firefox65 disabled, firefox66 disabled, firefox67 verified)

Details

()

Attachments

(4 attachments, 2 obsolete attachments)

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: 11 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1447778
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.
Status: RESOLVED → REOPENED
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)
Duplicate of this bug: 1447778

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
Posted 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
Status: REOPENED → RESOLVED
Closed: 11 months ago6 months ago
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

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
You need to log in before you can comment on or make changes to this bug.