Painting SVG images can spent a lot of time doing layout if it has multiple embed points |
||||||||||
Issue description
,
May 20 2016
From fs@opera: The reason FrameView::updateAllLifecyclePhasesExceptPaint is called where it is, is because of the FrameView::resize (and FrameView::processUrlFragment) call(s) at the beginning of the function. In turn the reason for that is the context-sensitivity of SVG image - depending on the embedding context sizes (and other things - c.f processUrlFragment) can change. I guess the interesting bit here is if this is a no-op or not. (9% sounds like an expensive no-op...)
,
May 20 2016
Why is an SVGImage adjusting size and url fragment in paint? That should be done during layout or earlier.
,
May 20 2016
The core of the problem I'd say is the 1:N mapping - a single SVGImage is mapped to multiple potential instantiation points ("viewports") in the document. Since there's still only one of most (all) things, one layout et.c would destroy the result of the previous (which will happened with different dimensions et.c.)
(I get a bit of a deja vu feeling here, but I couldn't find a dupe...)
,
May 20 2016
Ok. First step, I'm working on a patch to avoid updating the lifecycle if those two call sites have no effect.
,
May 20 2016
The patch removes a number of lifecycle calls. However, some of the stars in the animation for 'HTML suite > DOM particles, SVG masks' are of different sizes, and they all use the same SVG mask. Therefore with the current method of having one SVGImage to represent the mask with a single layout, we are forced to redo its lifecycle when it changes. In my tests the full lifecycle is dominated by layout, as one would expect.
,
May 20 2016
Looks like the mask (star) is made up of four (layout tree) nodes - and the way things currently all would be laid out. Could quite likely get that down only one (the root), but not sure whether that would make a noticeable difference or not - presumably depends on how the overhead is distributed.
,
May 23 2016
Unassigning this bug. I think any fix will require significant work and thought.
,
May 23 2016
In other words: I don't think we can significantly improve performance of this right now. Early-outing if the frame rect or fragment url didn't change did not have a huge impact on the referenced use case.
,
May 24 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 24 2017
,
May 24 2017
,
May 24 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 25 2018
,
Jun 4 2018
Issue 681611 has been merged into this issue.
,
Jun 5 2018
Issue 849470 has been merged into this issue.
,
Jun 5 2018
Hi, I'm surprised rendering of SVGs can be this slow. I've created a simple example that shows the problem clearly (below).
If this is an old known issue, is there also a known workaround? Is Chrome unable to handle many SVGs in general, or is there a specific way in which they need to be added? Chrome can hang up for 10+ minutes on a high performance machine if the page creates 1,000 trivial SVGs.
========================================
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<script>
function onLoad() {
for (let i = 0; i < 300; i++) {
let svg = document.createElement("OBJECT");
svg.className = "svg";
svg.type = 'image/svg+xml';
svg.data = "https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/android.svg";
document.body.appendChild(svg);
}
}
</script>
<style>.svg { width:24px; height: 24px }</style>
</head>
<body id="body" onload="onLoad()">
</body>
</html>
,
Jun 5 2018
,
Jun 5 2018
@c#18: This bug is about SVG images embedded in "image contexts" (<img> and various CSS properties for example.) That differs significantly from the case you demonstrate which is not an "image context". Your case is not very different from loading 300 iframes, although I think the loading pipeline interaction is worse off. You can test this out yourself by replacing "OBJECT" with "img" (and .data with .src) to notice the difference. This has been noted before in for example issue 608304. So while it's an interesting case, it's not the case this bug is about, so let's not conflate things.
,
Jun 5 2018
I should unmerge the bugs then.
,
Jun 7 2018
@c#20 Thanks for the input! Indeed replacing OBJECT with IMG changes the render time dramatically. (And unfortunately comes with other issues)
,
Sep 10
,
Dec 24
Issue 917600 has been merged into this issue. |
||||||||||
►
Sign in to add a comment |
||||||||||
![https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/android.svg";](https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/android.svg";){kind=link}
Comment 1 by chrishtr@chromium.org
, May 20 2016