scaling (with css) an svg which is animated (with css) produces pixelated output
Reported by
geop...@gmail.com,
Nov 11 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Open that attached page 2. Click on the button What is the expected behavior? After clicking on the button, the top (rotating) image should have the same size as the bottom one (it does) and it should be as clean and sharp as the bottom one (it does not). What went wrong? The rendered svg looks very pixelated. It seems that chrome rasterizes the svg when the document is loaded and it then keeps using the same initial low-res rasterization even when the image gets resized (by changing the scale in the css transform). Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 62.0.3202.75 Channel: stable OS Version: Flash Version:
,
Nov 13 2017
Thanks woxxom for bisecting! ajuma@ could you see if this is a relevant issue with the CL?
,
Nov 15 2017
We don't recompute raster scale during a CSS animation. The animated image starts out which scale 0.1 and scale doesn't change during the animation, so we compute that its max scale during the animation is 0.1, and raster it at the scale. But clicking on the button changes the scale on the container div to 1, so the new ideal scale for the image is 1. Before the CL from #1, we didn't try to compute the maximum scale for animations that involved rotation, so we used scale 1 as a fallback. Perhaps we should always raster with scale at least 1, no matter what maximum scale we compute for a CSS animation? That is, make sure that layers with CSS animations are rastered with at least the same scale we'd have used if they had a will-change:transform hint?
,
Nov 15 2017
Relatedly, adding will-change:transform to the ".image" class in the test case does workaround this bug.
,
Nov 15 2017
We are already doing that in the presence of will-change: transform. https://chromium.googlesource.com/chromium/src/+/e17b1bcf1010c97436fadf6e58e9235b977c74ea Sounds like we need to do this for css animations also. -> vmpstr for consideration.
,
Nov 15 2017
For css animations, afaik, we pick the maximum scale the element will be at throughout the animation. So, if we animate scale from 0.1 to 1.0 for example, then the animated element will be rasterized at scale 1.0. The problem in the testcase is that it's a combination of css transform and js updating the transform. I think the appropriate fix here is to actually have will-change:transform, since it's a hint that the transform of the element will change at some point on top of what css is doing. I don't think we should be rasterizing things at 1.0 at the minimum since it's likely to regress other css animations that keep their scale below 1.0 throughout the animation.
,
Nov 15 2017
After offline discussion with chrishtr@, we decided that this is a WontFix from Chromium's perpsective. The solution from the developer perspective is to add a will-change:transform hint that indicates to the browser that the transform for the element will change in some way that isn't readily detectable (ie js will change the transform). This will cause us to rasterize things at least at scale 1.0, avoiding the issue. Please re-open if this solution is not feasible and we can discuss further. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by woxxom@gmail.com
, Nov 11 2017