rendering layers through a parent layer with transform:scale() is blurry
Reported by
o...@framer.com,
Jul 10 2017
|
||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Steps to reproduce the problem:
1. Have a parent with transform: scale(0.7, 0.7).
2. With a child layer, give it an image (or text).
unexpected: the rendering is much more blurry than needed. Check Firefox or Safari to see a world of difference in quality.
```
<style>
#scale {
width: 800px; height: 400px;
/*will-change: transform;*/
transform: translate(0, 0) scale(1, 1);
}
#layer1 {
width: 320px; height: 200px;
transform: translate(100px, 10px);
background-image: url(test.png)
}
#layer2 {
width: 320px; height: 200px;
will-change: transform;
transform: translate(430px, 10px);
background-image: url(test.png)
}
</style>
<div id="scale">
<div id="layer1"></div>
<div id="layer2"></div>
</div>
<script>
setTimeout(() => {
scale.style.transform = "translate(0, 0) scale(0.7, 0.7)"
}, 500)
</script>
```
What is the expected behavior?
No unneeded blurriness.
What went wrong?
the rendering is much more blurry than needed. Check Firefox or Safari to see a world of difference in quality
Did this work before? Yes 47
Chrome version: 59.0.3071.115 Channel: stable
OS Version: OS X 10.12.5
Flash Version:
somewhat related to issue https://bugs.chromium.org/p/chromium/issues/detail?id=706273
,
Jul 10 2017
a minimal jsfiddle: https://jsfiddle.net/fagpka5v/2/
,
Jul 10 2017
Adapted the repro and moved to jsbin: https://output.jsbin.com/siquwub Attached is a screenshot chrome vs safari technical preview, taken on my new Macbook Pro with a 2.5 DPR. onne@, I don't know exactly what to look for here, so apologies for that. You're saying there isn't a blurring on the original in my jsbin? Is the `transform: translate(10px, 10px)` required to repro the blurring? Also it seems like this would repro just the same with an <img src>, as your div width/height is the natural size of the image. Is that correct?
,
Jul 10 2017
Thanks for looking into this! What you see can differ a lot based on display/computer. To verify screenshots, you will need to use zoom to 200% or more. (See new annotated attachment, on a 100ppi display.) To see the blur, check the top/left corner, or check the right side color bars, on Chrome these lost significant detail, the color bars are hardly colored anymore. I see that on 200ppi displays, chrome introduces more color/gamma artefacts, See the bottom row of squares, especially the left side. The blur is much less strong, but still Safari does better.
,
Jul 10 2017
As for the minimal reproduction, I don't think the translation is needed. And it is not just image content that gets blurred more than needed, text, svg, borders, all look way better on Safari/OSX on my 100ppi display. I'll verify canary when I hook it my laptop to the display tomorrow. Also verify if it is maybe an issue with mixing displays.
,
Jul 11 2017
Chrome Canary on my Thunderbolt display (109 dpi, 1 dpr) has a blur. Also if I turn laptop display off and restart Canary. Moving chrome window from my 1 dpr display to my 2 dpr display, will rerender and has significantly more quality. Maybe even more than Safari, because Safari shows some sharpening artefacts (higher contrasts than the original actually has). Hope this helps. Thanks again for looking into this.
,
Jul 11 2017
Tested this issue on Mac 10.12.5 with chrome #59.0.3071.115 with the provided url in the comment #0, while navigating the html didn't observe any blurriness. Observed the same behavior in safari too... Attaching the screenshot for reference. onne@ could you please look into it and let us know any steps i have missed while reproducing the issue.
,
Jul 12 2017
You will need a 1 dpr display (non retina). Check https://mydevice.io/ for CSS pixel-ratio.
,
Jul 12 2017
Thank you for providing more feedback. Adding requester "kkaluri@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
,
Jul 14 2017
Tested this issue on Mac 10.12.5 with Non-Retina display with chrome #59.0.3071.115, didn't observe any blurriness with provided html in comment #0. Attaching the screen-cast for reference. onne@ could you please look into it and let us know any steps i have missed while reproducing the issue.
,
Jul 14 2017
You looked at the images with browser at 400% zoom, similar to a `transform: scale(2.7, 2.7)` in this test. Instead, look at 100%, should be obvious then. Or take a screenshot and zoom in on that if you want to see the details.
,
Jul 14 2017
Thank you for providing more feedback. Adding requester "kkaluri@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
,
Jul 18 2017
I created a new test, and found some more hints to the cause here. 1. it matters if doing scale3d or scale. 2. it matters if more layers are nested 3. it matters if layers are scaled up or down Chrome in its worse case is adding a lot of blur, which even on 2 DPR is visible to "normal" people. But absolutely horrific on 1 DPR displays.
,
Jul 18 2017
The more blurred images are on composited layers. On linux Version 60.0.3112.50 (Official Build) beta (64-bit) the composited images are a little worse, but not very different to the non-composited case. Are we just re-scaling differently? Maybe it is mac specific? But I do not have a low-DPI Mac.
,
Jul 19 2017
Able to reproduce this issue on Mac 10.12.5(Low DPI), Win-10 and Ubuntu 14.04 using chrome reported version #59.0.3071.115 and latest canary #61.0.3160.0. This is a non-regression issue as it is observed from M52 old builds. From M51 and older builds on opening the test.html file doesn't show images as shown in attached screen shot. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Jul 19 2017
Ah, thanks, it might be that my "modern" javascript doesn't work on much older builds. Note the issue is not directly that a layer means blurry. But that the more deeply nested the layers, the more likely they are blurry, and the more blurry they might be. This makes framer prototypes look very blurry on chrome: https://framer.cloud/SLHMa/
,
Jul 21 2017
,
Jul 21 2017
vmpstr: can you take a look at this?
,
Sep 11 2017
Any progress? It is a serious problem for us at http://framer.com This is one of our examples on the site: https://framer.cloud/bOnIx where chrome vs safari is a world of difference in quality.
,
Oct 17 2017
We ran into this in AMP as well: https://github.com/ampproject/amphtml/issues/11597 (in AMP all <img>s are wrapped in a <amp-img> which makes this more common)
,
Mar 21 2018
Chrome is currently able to draw at high quality in these cases: a. Not composited (e.g. no 3D transform) b. Composited but without transform c. composited with 2D translation *only* For composited content with any non-1 scale factor, we do not currently optimize at subpixel resolution, so images may have some blurriness. Fixing this is not easy unfortunately (just doing (c) above was a whole lot of work). If you want to display an image with a scale, you can either fit into one of the cases above, or scale the image exactly to the desired pixel size on the server. The latter approach is more work for you, but will yield the highest quality results. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by o...@framer.com
, Jul 10 201765.7 KB
65.7 KB View Download