Issue metadata
Sign in to add a comment
|
Animating transform:scale can cause neighbours to shift |
||||||||||||||||||||
Issue descriptionForked from issue 840804 , reproducing content from OP there. Using Windows 7, Google Chrome 68.0.3425.0 (Official Build) canary (64-bit) (cohort: Clang-64) "Steps to reproduce the problem: 1. Navigate to https://jsfiddle.net/CoolCmd/79r1g4mo/ 2. Click the "Run" button at upper left corner. 3. Click the each of the white gears." "Another issue: Set Windows DPI to 150% and Chrome's font size to 40px. Sometimes pressing the gear changes position of the neighboring gears. I think this should not happen according to the standard." I have attached a local reproduction, and a screencast of me reproducing the issue. This is likely a regression from SPv175 so assigning to wangxianzhu@, but it is difficult to tell where it was exactly added due to the much more visually visible bug in issue 840804
,
May 9 2018
Tested in 67.0.3396.40. The issue still exists.
,
May 9 2018
I did manage to run a bisect, paying close attention for this particular issue and ignoring the jitter/shake from 840804. As expected, bisect point is SPv175 enabling.
,
May 9 2018
This looks like an issue about subpixel accumulation. We do discard subpixel accumulation when we cross a non-translation transform (because subpixel accumulation can't be transformed other than by a translation transform), so a shift and/or blurriness change may occur when a transform animates between translation-only transform and non-translation-only transform, e.g. scale animates between 1 to non-1. This is a fundamental issue of subpixel-layout and pixel-snapping, and we haven't seen a clean resolution for it. The jump of the gears after the animating gear seems abnormal though. Tien-Ren will take a look.
,
May 10 2018
wangxianzhu@, with hardware acceleration turned off, animation is smooth. "Fundamental issue" is limitation of Windows API?
,
May 15 2018
Re #c5: The "fundamental issue" is on all platforms, but it is visible only with subpixel layout which is triggered when there is subpixel units in the HTML, or the device scale is not integral and the "use-zoom-for-dsf" (dsf = device-scale-factor) feature is enabled (which is by default on Windows and Linux) in Chrome. I'm not sure how Windows hardware acceleration affects this. My speculation is that Windows API tells the app different device scale factors. Will investigate. For the gear shifting issue, you can try to workaround it by assigning absolute locations (e.g. position:absolute with explicit top and left values) to the gears so that their location won't depend on the previous ones.
,
Jun 8 2018
I think we are running into the same issue here or at least similar (no zoom or config needed). Tested on latest macOS (MacBook 13' 2013) especially on external non retina (but high dpi) screens. Chrome Version 67.0.3396.79 (Official Build) (64-bit) Just simply open the page and you should see the spinner jumping around. Attached a gif in case this is not reproducible on your machine. https://www.researchgate.net/application.ChromiumBugTest.html With Chrome 66 it worked just fine. Other observation is that the Chrome Helper is also using constant high CPU as long as the animation is running. Not sure if that was the case before.
,
Sep 14
I'm leaving the team, thus re-assigning. Not sure if this still repros. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by smcgruer@chromium.org
, May 9 2018784 KB
784 KB View Download