Issue metadata
Sign in to add a comment
|
Layout slow when "words" with a length greater than 15 are encountered in svg text
Reported by
kristoph...@gmail.com,
Apr 7 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Firefox/45.0 Example URL: http://bl.ocks.org/kmckenney/d3477682ae1e0309ff597116c274141e Steps to reproduce the problem: 1. Go to http://bl.ocks.org/kmckenney/d3477682ae1e0309ff597116c274141e 2. Expand a few filled in nodes contained in the d3js demo by left-clicking on them (expanding 6 nodes was more than enough to show very noticeable jank on my environment) 3. Click-drag on the background to start view panning What is the expected behavior? Smooth panning as in what I experience when using Firefox (Version 45.0.1) and Safari (Version 9.0.3 (9537.86.4.4)). What went wrong? Increasingly severe jank as more 16 character words are displayed. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? Yes Chrome version: 49.0.2623.110 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.9 Flash Version: 21.0.0.213 I've pinned it down to exceeding the 15 character "word" (consecutive non-whitespace characters) size. Replacing the data in the example with 15 character words will result in the same smooth panning seen in other browsers.
,
Apr 7 2016
This sounds like issue 589525 , and if so should be improved upon some in 50 and then some more in 51 (IIRC). So if you are able to test in something based on Chromium 50, that'd be great. (Tested on Opera 37/Chromium 50 on Linux and didn't see any jank with a number of nodes expanded.)
,
Apr 7 2016
Thanks for taking the time to file this. I think it's covered by 589525 which was a very unfortunate regression. There's a workaround in the bug where you can use foreignObject for text (super gross, but the best we can do until M51 makes it to stable).
,
Apr 7 2016
It definitely looks like a duplicate. I missed that one when I was searching through the issues. One bonus effect of the workaround is that it seems to seriously smooth out the zoom on a busy graph (at least on chrome), which still tends to have a fair amount of jank on all browsers (even when the panning is smooth).
,
Apr 8 2016
Can you try your page (pre workaround) in Chrome Canary and make sure it's fast? This bug should be fixed in Canary. SVG doesn't have layers so it's difficult to signal to the browser that you want to pan something without changing the contents. A common workaround (particularly for webkit-based browsers) is to put the panning content in a div with a transform, then change only the div's transform. This may not be possible for your content, but it's worth a shot. If you are seeing other perf issues, please do file a bug.
,
Apr 8 2016
I can confirm that the Chrome Canary build fixes the documented issue. The panning is smooth with the current Chrome Canary (Version 51.0.2703.0 canary (64-bit)). On a side note, the zoom isn't as smooth as when the gross workaround is used. However, it is roughly on par with Firefox (to the naked eye). |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rsesek@chromium.org
, Apr 7 2016