Issue metadata
Sign in to add a comment
|
Chrome downgrades render quality of SVG images when their file size is above ~3kB
Reported by
seanpram...@gmail.com,
Apr 11 2017
|
||||||||||||||||||||||
Issue description
Chrome Version : 57.0.2987.133
OS Version: OS X 10.12.4
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:
What steps will reproduce the problem?
1. In Chrome, open an SVG file with a size of less than 3kB (attached)
2. Note rendering quality (smooth edges with good anti-aliasing)
3. In Chrome, open an SVG file with a size of more than 5kB (attached)
4. Note rendering quality (jagged edges with poor anti-aliasing)
What is the expected result?
SVG files render smoothly regardless of size.
What happens instead of that?
SVG files larger than ~3kB are rendered at a lower quality.
Please provide any additional information below. Attach a screenshot if
possible.
- The issue occurs when a single SVG element is too large, or when two separate SVG elements have a combined size that is too large
- Wrapping the SVG code in DIVs or other elements does not resolve the issue
- Changing the shape-rendering or image-rendering attributes do not resolve the issue
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
,
Apr 11 2017
It looks like we end up using different rendering code-paths in these two cases, and the latter (larger) is rendered with a path that uses fewer "samples"/coverage levels (4 or so?) per pixel. Could you attach the contents of of chrome://gpu?
,
Apr 11 2017
Tested in chrome # 57.0.2987.113 and Canary #59.0.3068.1 on Mac 10.12.3 and not able to reproduce the issue.Please find the screen shots for your reference. @Reporter: Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once and let us know the observations of the issue which would help us to triage the issue further. Thanks in Advance.
,
Apr 11 2017
,
Apr 11 2017
,
Apr 11 2017
,
Apr 11 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 11 2017
seanpramsey@, can you navigate to about:gpu and either paste or attach the contents of that page? That will give us a bit more info about your configuration and my help us narrow down the issue. Thanks!
,
Apr 11 2017
OK, tracked this down - the rough-edged look is happening with the MSAA path renderer in GPU raster. non-MSAA GPU raster and SW raster look fine. senorblanco@, is the MSAA path going to go away when the veto is removed? Or will we still use it for some cases? If it's going away, we may just want to double-check that this case looks good with the new system.
,
Apr 11 2017
We're keeping the veto-to-MSAA and MSAA path renderer where available. At a rough guess from the PNGs, this looks like we're getting 2 samples of MSAA, which should never happen: it should require a minimum of 4 on HiDPI or 8 or LoDPI. about:gpu would be very helpful.
,
Apr 11 2017
Looking at the quality of the AA in the picture attached to #1, it does appear that the user is getting 2xMSAA - I thought I could repro locally, but I appear to be getting 4xMSAA, which doesn't look nearly as bad. Attached a reference image.
,
Apr 11 2017
I think we need about:gpu to make forward progress on this. seanpramsey@, could you provide that when you get a chance?
,
Apr 11 2017
From looking at your about:gpu, it appears that you are forcing GPU MSAA sample count to 2 (either via about:flags or via --gpu-rasterization-msaa-sample-count). Resetting this to "Default" in about:flags or dropping the command line should address the quality issue. FWIW, you're also using the "--ignore-gpu-blacklist" flag, which should be unneeded on your system (your GPU config should be fully supported at this point), and can lead to stability issues (although should just be a no-op on your system). Let me know if removing the --gpu-rasterization-msaa-sample-count command line or ressetting "GPU rasterization MSAA sample count." category in about:flags fixes the problem. Thanks!
,
Apr 14 2017
loorongjie@, it seems like your system is using software rasterization, so I don't think this is the same issue. Can you attach a screenshot of what you're seeing? Thanks!
,
Apr 17 2017
Sorry for the late reply. I disabled the two settings you mentioned (--gpu-rasterization-msaa-sample-count and --ignore-gpu-blacklist) and it improved anti-aliasing slightly, but it stills renders differently that when there is only one instance of the image (see attached).
,
Apr 18 2017
This appears to be working as intended. With a sufficient number of concave paths, we will use 4xMSAA on high-DPI devices, which will have different results than the software-and-upload (CPU) path. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tapted@chromium.org
, Apr 11 2017