Animation when zoomed causes text to blur and/or jiggle |
||||||
Issue descriptionVersion: m50 OS: Linux probably all What steps will reproduce the problem? (1) Open Google Keep and zoom to 125% (2) Hover over some text to invoke the hover animation (3) Watch the text in the entry blur or shift up/down a pixel during the animation, and also text in some other unrelated entries blur (presumably those squashed into the same layer) What is the expected output? Non blurring/jittering text during the animation What do you see instead? Text blurs during animation, even on non-animated elements It doesn't seem to reproduce entirely reliably. It only seems to affect layer squashed elements. Someone who knows more about animation and layers can probably explain this behavior. I would be less offended if only the animated element was affected.
,
Apr 27 2016
Can repro linux M51.
,
Apr 29 2016
Able to repro this on the latest canary(52.0.2720.0) on Windows-7, Mac OS 10.11.4 and Linux Ubuntu 14.04. Google Keep requires atleast chrome version M-45 to install. Checked this on chrome version: 45.0.2406.0 and this behaves the same on that chrome version as well. Triaging this as Non-regression issue reproducible across all OS.
,
May 1 2016
,
May 4 2016
If you turn on show layer borders in dev tools, it looks like we're temporarily promoting subsequent notes in keep to be in their own composited layers for the duration of the animation. I believe we can no longer do subpixel anti-aliasing when this happens - which could be the source of the blurriness / jitteriness. What seems to be happening is that during the shadow animation on hover we promote the outer div to its own layer which grows to overlap slightly with adjacent divs. However, this div is supposed to be underneath all of the divs which follow it in page order - this means that we also have to promote all of these which may overlap the expanded shadow in order to ensure the correct stacking order. I've confirmed that adding z-index: 1 on hover prevents this layer creation when you hover over the element (still happens when you move off because the z-index: 1 is removed before the animation completes).
,
May 6 2016
The reason the entire note is promoted is that it has a transform and we begin animating descendants of it. Its descendants being animated on the compositor thread need to know the note's transform and so the note becomes composited. Then, because the composited note could overlap the notes following it on the page all of the following notes need to be promoted. I think the right thing to do here is set z-index: 1 on hover to state that we don't care if the note might overlap the other notes because it's on top anyways, and then remove z-index: 1 on transition end when the mouse leaves. That's probably the best we can do, it otherwise seems to be working as expected.
,
Jun 4 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by schenney@chromium.org
, Apr 27 2016