SVG repaints, memory growing and crash
Reported by
dominik....@gmail.com,
May 9 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36 Steps to reproduce the problem: 1. Open testcase in Chrome: http://codepen.io/dom1n1k/pen/PNVEvX 2. Open Chrome test manager (Shift+Esc) 3. Watch memory consumption of this tab 4. Memory will grow fast 5. About ~3.5 gigs Chrome (32 bit version) will crash! Guaranteed :) What is the expected behavior? Infinite animation What went wrong? Memory grow and Chrome crash Crashed report ID: How much crashed? Just one tab Is it a problem with a plugin? No Did this work before? N/A Chrome version: 50.0.2661.94 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0 Brief description. I have: 1. SVG with large amount elements. 2. Elements are filled with gradients. If replace gradients to solid colors, gradient, the bug is still there, but we need more elements. 3. Heavy raster SVG-filter. 4. Heavy CSS animation. Whats happend? 1. Animations -> many, many repaints. 2. Because the filter, browser can not optimize repaint regions. He repiants always all! 3. Because the gradients and elements count, it's eats a lot of memory. 4. GC too weak and too slow :) Thanks And sorry for my bad english.
,
May 12 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/589ab53f384e1e8a0df92eb868acf3ea35839a2e commit 589ab53f384e1e8a0df92eb868acf3ea35839a2e Author: fs <fs@opera.com> Date: Thu May 12 17:27:40 2016 Don't store an SkPicture in the SourceGraphic FilterEffect Instead of storing the SkPicture in the SourceGraphic FilterEffect, just create a filter and pre-populate all the image filter "slots" when we've recorded the content that should be filtered. This avoids keeping an explicit reference to the SkPicture, and thus avoids keeping this object alive when the Filter and it's associated filter-chain is in limbo waiting for a Oilpan GC sweep. BUG= 610158 Review-Url: https://codereview.chromium.org/1961083006 Cr-Commit-Position: refs/heads/master@{#393280} [modify] https://crrev.com/589ab53f384e1e8a0df92eb868acf3ea35839a2e/third_party/WebKit/Source/core/paint/SVGFilterPainter.cpp [modify] https://crrev.com/589ab53f384e1e8a0df92eb868acf3ea35839a2e/third_party/WebKit/Source/platform/graphics/filters/FilterEffect.cpp [modify] https://crrev.com/589ab53f384e1e8a0df92eb868acf3ea35839a2e/third_party/WebKit/Source/platform/graphics/filters/SkiaImageFilterBuilder.cpp [modify] https://crrev.com/589ab53f384e1e8a0df92eb868acf3ea35839a2e/third_party/WebKit/Source/platform/graphics/filters/SkiaImageFilterBuilder.h [modify] https://crrev.com/589ab53f384e1e8a0df92eb868acf3ea35839a2e/third_party/WebKit/Source/platform/graphics/filters/SourceGraphic.cpp [modify] https://crrev.com/589ab53f384e1e8a0df92eb868acf3ea35839a2e/third_party/WebKit/Source/platform/graphics/filters/SourceGraphic.h
,
May 13 2016
With the fix above, the growth seems to have stopped.
,
Apr 5 2017
,
Apr 26 2017
The bug is still actual. As before, memory grows and tab crashes. However, a bit slower than before (visually). Chrome 58.0.3029.81 (last stable).
,
Apr 26 2017
fs@, mind taking another look?
,
Apr 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/824d3f765ad699054db51cc21c7a9deb8d17a947 commit 824d3f765ad699054db51cc21c7a9deb8d17a947 Author: fs <fs@opera.com> Date: Fri Apr 28 13:50:13 2017 Proactively dispose image filters for SVG filter chains Because of the spanning of multiple heaps by the resources associated with FilterEffects [GCd] (SkImageFilter [mallocd]), the garbage collector only observes a relatively slow growth, while resources tied by or via the other heap can be substantial. Since we have fairly good control of the lifetimes here, we can try to dispose of our references to the resources on the other heap up front, and prevent growth due to (dead) GCd objects in limbo. Also rename FilterEffect::ClearResult to DisposeImageFilters to better match it does nowadays. BUG= 610158 Review-Url: https://codereview.chromium.org/2846593008 Cr-Commit-Position: refs/heads/master@{#467983} [modify] https://crrev.com/824d3f765ad699054db51cc21c7a9deb8d17a947/third_party/WebKit/Source/core/layout/svg/LayoutSVGResourceFilter.cpp [modify] https://crrev.com/824d3f765ad699054db51cc21c7a9deb8d17a947/third_party/WebKit/Source/core/svg/graphics/filters/SVGFilterBuilder.cpp [modify] https://crrev.com/824d3f765ad699054db51cc21c7a9deb8d17a947/third_party/WebKit/Source/platform/graphics/filters/FilterEffect.cpp [modify] https://crrev.com/824d3f765ad699054db51cc21c7a9deb8d17a947/third_party/WebKit/Source/platform/graphics/filters/FilterEffect.h
,
Apr 28 2017
Ok, second times the charm I hope... I'll give the original reporter some time to verify that the issue is indeeed fixed this time (new fix should be in tomorrows Canary I hope.)
,
Apr 28 2017
,
Apr 30 2017
Yes, in last Canary 60.0.3085.0 works fine. About 150-160 mb of memory. Thanks!
,
Apr 30 2017
Thank you for the verification! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by f...@opera.com
, May 9 2016Labels: -OS-Windows OS-All
Status: Available (was: Unconfirmed)