Issue metadata
Sign in to add a comment
|
Very slow SVG raster hardware acceleration
Reported by
matan...@gmail.com,
Sep 13
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Example URL: Steps to reproduce the problem: 0. Install chrome 61+ and be on an affected platform (I can't yet narrow it down enough for specific CPU/OS, see below) 1. Have a website with large, preferably interactive (i.e pan and zoom) svg 2. Suffer from extremely bad SVG rasterization times. 3. Workaround possible by disabling HW acceleration. What is the expected behavior? Smooth svg performance - fast raster times. What went wrong? I'm a web developer working on an internal company site which displays rather large SVG images, which are interactive (pan and zoom, mainly). Since Chrome 61+, we noticed that on some of our (developers) and users PCs, the SVG performance we really degraded. Nothing changed on the machine - installing older Chrome version solves the issue. This happens on multiple OSes (Windows and Linux), on Intel CPUs (we don't have AMD) all without a discrete GPU. On some of the PCs this doesn't happen, but it's hard for us to narrow the bug criteria down since it does affect many PC models. After a bit of researching, our current workaround it to instruct our users to disable hardware acceleration altogether for now. This results in much better performance. I profiled the issue on my local dev machine(s) (Windows and Linux), and it seems that indeed the raster operations just take very long time. Interestingly, when inspecting a raster "block" on the profile timeline, the times in the call tree tab does not add up to the actual time the raster operation took (I'm not sure if this is a good lead, but I wrote it anyway). Since I noticed that in Chrome 61 the issue exists but in 60 it does not, I looked at the changelog (https://chromium.googlesource.com/chromium/src/+log/60.0.3112.78..61.0.3163.79?pretty=fuller&n=10000) from 60 to 61, but I couldn't find a smoking gun related to this issue. I'm not sure how to even start debugging this. I guess I'd like to profile Chrome itself somehow, but I'd like a bit of guidance beforehand, if that's possible. Thanks! Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.92 Channel: stable OS Version: 7 Flash Version:
,
Sep 13
,
Sep 13
,
Sep 13
Just a quick note, when looking at the chrome://gpu page (on both versions - 60 (good) and 61 (buggy)), everything looks fine without any issues. (I cannot copy the chrome://gpu page here for reference due to company policy, but if you have any questions about it, I'd be happy to answer).
,
Sep 13
Thanks for the report! Would it be possible for you to share the webpage you repro the issue on? I'd like to be able to see the same thing on my end that you do.
,
Sep 13
Currently I'm not at the office, but I'll create a small demo that reproduces the issue on the effected machines on Sunday. Since the issue seems to be somewhat platform specific (and it probably wouldn't reproduce anyway on your machine), is there anything else I can do on a known affected machine? Surely there is a relatively comfortable way to profile Chrome rendering on a lower level. I have no problem building from source, but I'd like to have some pointers on where to look at.
,
Sep 14
,
Sep 14
Needs-FB as per C#5.
,
Sep 14
,
Oct 1
The NextAction date has arrived: 2018-10-01
,
Oct 8
The root cause of this was probably a change to the GPU blacklist, or more likely a change to paths GPU raster. Given the age of the version involved, and the workaround, I think we need to WontFix this. Re-open if the issue persists or if software workaround is insufficient. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by meh...@chromium.org
, Sep 13