bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Over invalidation when scrolling SVG containing a large number of elements (jank)

NEW
Assigned to

Status

()

Core
SVG
6 years ago
3 months ago

People

(Reporter: jwatt, Assigned: jwatt)

Tracking

(Depends on: 2 bugs, {perf, regression})

17 Branch
perf, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox17-, firefox18-, firefox19-)

Details

(Whiteboard: [invalidation] [in-the-wild], URL)

(Assignee)

Description

6 years ago
+++ This bug was initially created as a clone of Bug #800198 +++

STR:
1) Open this SVG demo: http://www.jasondavies.com/factorisation-diagrams/
2) Scroll the page with the vertical scrollbar or the middle button

Result: 
Scrolling is slowed down and isn't as smooth as in FF16. After scrolling the page during a while, f you switch to another tab then you come back, there is a slight hang to display the tab with the SVG demo.

m-c
good=2012-08-02
bad=2012-08-03
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=588424024294&tochange=89dcadd42ec4

There are some bugs about SVG patches, like bug 655877 or bug 776054.
(Assignee)

Comment 1

6 years ago
Alice commented in bug 800198 comment 1:

Regression window(cached m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/a799b5bff84c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120801155239
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b077c43a4306
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120801163038
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a799b5bff84c&tochange=b077c43a4306

And svg.display-lists.painting.enabled = false helps
(Assignee)

Comment 2

6 years ago
A lot of the slowness I'm seeing here on m-c is due to bug 801918.
Depends on: 801918
(Assignee)

Comment 3

6 years ago
Another source I've isolated is bug 802321.
Depends on: 802321
(Assignee)

Updated

6 years ago
Keywords: perf
(Assignee)

Comment 4

6 years ago
I had to rebuild my Windows machine over the weekend, but I now have a Windows build environment and I _can_ see scrolling get a little clunkier over the regression range given in comment 1 on Windows. That said, that slowdown is completely dwarfed by the DLBI issues that I've been isolating from this bug over the last few days (bug 801918, bug 802440, the issue fixed in bug 800198, and the two issues fixed in bug 802321). I'm guessing tracking was granted based on the much larger slowdown caused by these issues, so we may want to revisit the decision to track after they're fixed. (Which is to say that, while we definitely want to fix the regression identified in comment 1, that issue may not be severe enough to warrant tracking.)
(Assignee)

Comment 5

6 years ago
Oh, and the regression from comment 1 is not an invalidation issue. (Sadly, since that would make it easier to identify the fix.)

Comment 6

6 years ago
Unless we think this will cause major web regressions, we're very likely to untrack for FF17/18. Please let us know if that's a problem.
Untracking for 17, Jwatt can you give a status update and eta on a fix for 18?
tracking-firefox17: + → -
(Assignee)

Comment 8

6 years ago
There's not much point in me fixing this for 18 until bug 801918 is fixed since that issue is much more severe than the original. Even if that was fixed now, I've no idea when I'll get to this since I have plenty of other higher priority bugs assigned to me right now.

Comment 9

6 years ago
Yep, this isn't the end of the world and we don't know of any major affected web properties. No need to track for upcoming releases at all in that case - glad we agree.
tracking-firefox18: + → -
tracking-firefox19: + → -
(Assignee)

Updated

6 years ago
Depends on: 802440
(Assignee)

Comment 10

6 years ago
Despite bug 800198, bug 801918, bug 802321 and bug 802440 now being fixed I'm still seeing frequent full page invalidation when scrolling the reported page. I'm also seeing weird smaller invalidations around the fringes of the SVG blocks while they're in the center of the page while scrolling.
(Assignee)

Updated

6 years ago
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: Scrolling slowdown and hang on SVG demo → Scrolling has become jerky on SVGs containing a large number of elements (jank)
(Assignee)

Comment 11

6 years ago
It seems like the majority of the time is being spent under ContainerState::ProcessDisplayItems and BuildDisplayList. The JS in the demo generates a very large number of SVG elements, and the result is that we end up creating a very large number of display list items.

One of the concerns I voiced prior to converting SVG to use display lists was that more complex SVGs would take a perf hit from the overhead of creating and handling the number of display list items they'd require (SVGs are more likely to contain many, many more onscreen elements than HTML is). Maybe someone who understands layer generation better can see a bug in ContainerState::ProcessDisplayItems that might be causing an issue here, but otherwise, on Windows at least, I think that's largely the problem that this SVG demo is encountering. (On Mac there's still the frequent full page invalidation thing going on too.)
jwatt and I profiled this just now - the invalidation looks ok now, at least in Nightly on Windows (I've not tried elsewhere), but the profile showed an inordinate amount of time being spent in ProcessDisplayItems.

Although drawing is high in the profile, resizing the window to be the same width horizontally, but very narrow vertically, the frame-rate improves markedly. This goes some way to pointing towards display list processing being the problem, as having less visible on the screen would reduce the size of the display list a lot.

Although this is probably a pathological case (many, complex SVGs, visible at once), this is of some concern to mobile. On mobile, we render a larger area than the screen, and an even larger area than that (by a factor of 4) when rendering is deemed to not be keeping up. Polynomial display list processing costs would not be desirable in that case.

I have no clever ideas of how to fix this just now... I expect we want some kind of caching of the work that is done in ProcessDisplayItems so that we can avoid spending a long time on branches of the display list that never change.
Just to add some quantities to comment #11 and comment #12, taking a profile of scrolling up and down on my machine and taking the time in nsRefreshDriver::Tick:

gfx::DrawThebesLayer - 46.7% (mostly spent in paint and fill)
ContainerState::ProcessDisplayItems - 33.9%
ViewportFrame::BuildDisplayList - 10.1%
nsDisplayList::ComputeVisibilityForRoot - 5.1%

Nothing else shows up in a way that's worth mentioning.
(In reply to Chris Lord [:cwiiis] from comment #12)
> Polynomial display list
> processing costs would not be desirable in that case.

The processing time should be linear in the number of visible items, not super-linear.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #14)
> (In reply to Chris Lord [:cwiiis] from comment #12)
> > Polynomial display list
> > processing costs would not be desirable in that case.
> 
> The processing time should be linear in the number of visible items, not
> super-linear.

My bad, that's good to know then. That makes this less worrying, though I suppose it'd still be good to cache something somewhere to avoid unnecessary work. He says, vaguely.
(Assignee)

Comment 16

6 years ago
Fixing bug 828240 might help here, but probably not by all that much.
Depends on: 828240
(Assignee)

Updated

5 years ago
Duplicate of this bug: 840503
(Assignee)

Updated

5 years ago
Depends on: 869505
(Assignee)

Updated

5 years ago
Whiteboard: [jwatt:invalidation]
(Assignee)

Updated

5 years ago
Whiteboard: [jwatt:invalidation] → [jwatt:invalidation] [in-the-wild]
Depends on: 1016525
Comment hidden (metoo)

Comment 19

4 years ago
Performance improved dramatically when I last checked it two weeks ago. It appears to have regressed again.
I can not reproduce this issue on Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

I will close this bug. Please feel free to reopen if the bug persists.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
(In reply to Justin [:JW_SoftvisionQA] from comment #20)
> Please feel free to reopen if the bug persists.

Indeed it does, just compare current release (non-e10s) and trunk (e10s) with/against ESR 10 - difference like day and night ...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
(Assignee)

Updated

a year ago
No longer depends on: 828240
(Assignee)

Updated

a year ago
Summary: Scrolling has become jerky on SVGs containing a large number of elements (jank) → Over invalidation when scrolling SVG containing a large number of elements (jank)
Whiteboard: [jwatt:invalidation] [in-the-wild] → [invalidation] [in-the-wild]
(Assignee)

Comment 22

7 months ago
Having the layout.display-list.retain pref set to true makes a noticeable difference when scrolling quickly from the top to the bottom of the page.
Depends on: 1352499

Updated

3 months ago
Depends on: 1446667
You need to log in before you can comment on or make changes to this bug.