New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 839820 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Incorrect CSS transform scaling at high DPI

Reported by cyder...@gmail.com, May 4 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36

Steps to reproduce the problem:
1. Set Windows display scaling setting to 125% on high DPI display 
2. Use CSS to scale an element by a large amount (seems to have a more noticeable effect at high CSS scaling factors)

What is the expected behavior?
Scaling will occur by the desired amount (final size = scale factor * original size), regardless of OS high DPI scaling setting.

What went wrong?
Scaling becomes inconsistent with high DPI scaling as shown in the test case. All boxes should be of the same size. The results change when using other high DPI scaling settings 
 - 150% or 175% generates different but still incorrect results

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 66.0.3359.139  Channel: stable
OS Version: 10.0
Flash Version: 

This works correctly if the high DPI scaling is turned off (100% in Windows display settings)
 
scaling_test.html
1.3 KB View Download
scaling_test_settings.png
27.4 KB View Download
scaling_test_results.png
13.8 KB View Download
Labels: Needs-Triage-M66
Cc: sindhu.chelamcherla@chromium.org
Labels: M-68 FoundIn-68 Triaged-ET Target-68
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on reported version 66.0.3359.139 and on latest canary 68.0.3323.0 using Windows 10 when scaling is 125% and resolution is 1920x1080. Issue is not reproducible on HiDPI Linux with same resolution and Mac.

This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as untriaged.

NOTE: Issue is working fine in Firefox and Edge.

Thank!


Comment 3 by e...@chromium.org, May 8 2018

Status: WontFix (was: Untriaged)
This also reproduces when zooming and despite the unexpectedness of it is actually working as intended. 

When zooming (or adjusting DPI) we always align elements with the displays pixel grid so that an element that has a resulting width of 2.5 device pixels will be adjusted to 2 or 3. If we didn't do this the resulting element would look blurry as either the left or right edges would be antialiased.

In Chrome CSS transforms take effect after layout and as such are affected by, and compound, the rounding differences.

With scale(25) the 1px difference between rounding up or down turns into a 25px difference, which is the effect you're seeing in the attached test case.

Comment 4 by cyder...@gmail.com, May 9 2018

Okay, I figured it was something like this; indeed zooming does exhibit the same behaviour.

It's a little perplexing that the CSS transforms only happen after the rounding and not before. Is there a reason why the transforms only happen after layout? CSS doesn't really affect layout I suppose, so it makes some sense to have them afterwards, but then this results in these compounding rounding errors.

I imagine that if CSS transforms were applied before rounding, then high quality output would always be achieved, but I'm probably misunderstanding something about the architecture used here. Are there any design documents that discuss why the current method was chosen?

In any case I suppose there are much more important things to be working on in Chromium anyway, so thank you for taking a look at this issue.

Sign in to add a comment