Control image quality after transform scaling
Reported by
flashrab...@gmail.com,
Dec 5 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: - Let's assume that we have a large image - 4000x4000px, its size is defined via CSS as "width:100px;height:auto;". - We want to animate image from 100px to 4000px. - So we apply CSS transition style and "transform: scale3d(40,40,1)". It animates smoothly. - At the end of the transition, we remove scale transform and set explicit size via CSS to "width:4000px". We do not need to do this in Chrome as it improves quality automatically. But we do need to do this for others browsers, for example, the latest Safari. All is good. Now the hard part. We want to scale "width:4000px" image back to 100px. If we just apply scale "transform: scale(0.025)" - the animation will lag, since we are animating huge 4000x4000 image. Sometimes Chrome automatically switches resolution during the transition, but it causes significant lag and image disappears for a few milliseconds. The first idea that comes to mind is to reverse opening transition via so-called "FLIP" technique. So we force size "width:100px;", apply transform "transform: scale3d(40,40,1)". Then wait like 100ms to give browser time to render this 100x100 tile and only then run animation. But it doesn't work. Image is still rendered at a full resolution. Unfortunately, Chrome does not understand difference between "width:4000px" and "width:100px;transform: scale3d(40,40,1)". Is there a way to force resolution on the image? What is the correct way to do such kind of transition? Other browsers: - Safari never improves image quality - Firefox always renders image quality at its visible size. Video that shows how it works in Chrome/FF/Safari - https://streamable.com/zaus8 (and JSfiddle https://jsfiddle.net/cLpcbadg/ , though you'll need slow enough machine or large enough image to reproduce). What is the expected behavior? What went wrong? - Did this work before? N/A Does this work in other browsers? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: OS X 10.13.0 Flash Version:
,
Dec 6 2017
Moving over to the compositing people because I think animation resolutions live there. This is a hard problem: we generally prefer to leave resolutions constant during animation to avoid work, and on the GPU I would expect the downsizing animation to be pretty fast if the image is direct composited. Over to the Compositing team for insight on what if anything we can do. Note also that the result might depend on (a) hardware acceleration status and (b) the just enacted change to remove all high-quality filtering.
,
Dec 6 2017
@schenney Thank you, so is there a recommended way to run such animation? If the answer is "do not animate 4k image", what's the maximum safe size?
,
Dec 15 2017
While will-change:transform is on an element, it won't re-raster at different scales. So you could make a 100x100 element, put that on it, and swap it in with a large scale and animate it down? +vmpstr to fact check me
,
Dec 15 2017
@danakj, that is very helpful, thanks!
,
Mar 5 2018
Mac triage: WontFix issue with no clear forward path. |
||||
►
Sign in to add a comment |
||||
Comment 1 by sdy@chromium.org
, Dec 6 2017