1238328 - Increase memory consumption SVG pie chart when mouse move over it

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Alice0775 White]

[Tracking Requested - why for this release]:

+++ This bug was initially created as a clone of Bug #1238250 +++

This happens Nightly46.0a1, but not on Aurora45.0a2.

STR
1. open attachment 8705975 [details]
2. mouse move over SVG pie chart for a while

Actual Results:
Increase memory consumption in a very short time. about 30MB/sec

Expected Results:
not so

Comment 1

[Alice0775 White]

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=36c1e4eb0c9141aae4071a917ce4e3a59f5a79c6&tochange=d74084d072f0b5dfb00e3fbc103bef0a3fecbf85

Regressed by: Bug 1220629

Comment 2

[Alice0775 White]

Attachment: before mousemove

Comment 3

[Alice0775 White]

Attachment: after mousemove, GB memory usage

Comment 4

[Alice0775 White]

Attachment: about:support

Comment 5

[Mayank Bansal]

Attachment: memory-report.json.gz

this is with e10s turned off. The windows task manager shows firefox.exe taking 2.1GB memory.

Comment 6

[Bas Schouten (:bas.schouten)]

So this SVG does an insane amount of push/poplayers, each one seems to add just a little bit of GPU memory usage but they only get cleared when the DrawTarget is destroyed, this seems like D2D being very suboptimal, I'm investigating.

Comment 7

[Bas Schouten (:bas.schouten)]

Upon further investigation it is observed that this memory increase is not the result of the PushLayer/PopLayer itself, or the rendering of the command list to the context, it is rather the result of drawing to the command list. I suspect drawing to a command list generates some sort of intermediate GPU resources for the command list that aren't cleared when the last reference to the command list is released.

Comment 8

[Bas Schouten (:bas.schouten)]

Extensive investigation into why this happens shows that D2D will internally maintain references to any command lists that -have- been used with a certain device context, until EndDraw is called on that device context. Since command lists will hold on to resources used to draw to them that can cause quite a growth in memory usage. A 'simple' fix would be to on a flush do an End/BeginDraw pair instead of just a flush. I've done a try push to see how this will affect performance. If the performance implications are too severe we can keep track of how many command lists have been pushed and only do an End/BeginDraw above a certain threshold.

Comment 9

[Bas Schouten (:bas.schouten)]

Attachment: MozReview Request: Bug 1238328: Purge stored command lists by calling EndDraw/BeginDraw on a regular basis when they're used. r=jrmuizel

Review commit: https://reviewboard.mozilla.org/r/30337/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/30337/

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8706391 [details]
MozReview Request: Bug 1238328: Purge stored command lists by calling EndDraw/BeginDraw on a regular basis when they're used. r=jrmuizel

https://reviewboard.mozilla.org/r/30337/#review27171

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c88ad0a6f5df

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c88ad0a6f5df

Comment 13

[u279076]

Alice, can you please confirm this is fixed in tomorrow's Nightly build?

Comment 14

[Alice0775 White]

Reproduced on Nightly 2016-01-11 build.
https://hg.mozilla.org/mozilla-central/rev/6020a4cb41a77a09484c24a5875bb221714c0e6a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20160111030207

And I can verify that the problem is fixed on Nightly 2016-01-12 build.
https://hg.mozilla.org/mozilla-central/rev/e790bba372f14241addda469a4bdb7ab00786ab3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20160112030227

Comment 15

[u279076]

Thanks for your help, Alice.