Position fixed/absolute layers jump when composited
Reported by
dimanechepurenko@gmail.com,
Nov 2 2017
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36 Steps to reproduce the problem: 1. Scroll to the box with text, so the fixed panel will be over the box. 2. Hover over the box and back to the fixed panel. 3. Layer for panel are painted differently so it cause twitch effect. This issue happens in some cases, probably, it depends on other thing, but anyway it is reproducible in this reduced case. If nothing is happen, scroll back to document top and try again. It is more often happen when default (retina monitor or OS scaling factor) or manual scaling applied to the page. What is the expected behavior? No twitch effect happen when root layer part moved to another layer. What went wrong? Elements are twitching by some interaction. Did this work before? No Does this work in other browsers? No This is reproducible in desktop Safari and Opera. Chrome version: 62.0.3202.62 Channel: stable OS Version: Version 62.0.3202.62 (Official Build) (64-bit) Flash Version: This is old issue (I have seen it about 5 years ago or so), but I did not found any ticket related to this (I believe it should be). The workaround is manual push element to layer by using: `backface-visiability: hidden`, `will-change: transform|opacity`, `transform: translate3d(0,0,0)` etc. This this is hard to manage, force to do things that can cause potential performance issue and lead to technical overhead.
,
Nov 3 2017
Hi there, Thank you for your thoughts! I prepare the case with position absolute connected to scroll offset. On my screen it each 3rd element, on different screen it could be 2nd or so.
,
Nov 14 2017
Hi there, any updates?
,
Nov 14 2017
We're not likely to fix this quickly because the result will change with major implementation changes that are currently in progress. When those are done we'll know if the issue persists and hence how to fix it in the new system.
,
Nov 15 2017
Hi Schenney, Thanks for quick answer! It is pretty reasonable. I understand that you could not commit any dates, so it would be great if someone from the team keep tracking this issue and keep updating a status. Thanks!
,
Dec 26 2017
Hi, Any updates about this issue?
,
Dec 28 2017
I think what you are observing is the effect the content becoming composited during the animation or hover. In the case of the images of the woman, there is an opacity animation for 0.4s, during which the image becomes composited due to that animation, and the blend of opacity in the compositing code being slightly different than the non-compositing. You can prevent the artifacts by always being in one mode or another. will-change: transform forces compositing, you could apply that on hover. Note also that there is no way in Chrome right now to turn off that comositing, except by implementing the animation curve yourself. For the fixed-position example, I can't reproduce it. It should not be happening on Retina because we always composite fixed-position elements on such screens. The same kind of advice applies there. I'm going to close this bug, because it's not feasible to somehow make every rendering mode which utilizes different algorithms, end up with the exact same rounded floating-point result, even though in principle perhaps they could. We do care about subpixel accuracy of offsets of content being correct, but as far as I can tell from these examples, there are no problems with that code exhibited by these examples.
,
Jan 11 2018
Hi Chrishtr, Obviously you are right this bugs would not be possible without opacity and transformation that cause composition and we already have a workarounds for this stuff. Could you confirm that mentioned by you approaches not lead to performance issues if people start to actively use it as a workaround?
,
Jan 19 2018
Unfortunately, compositing is always going to be a performance tradeoff. For example, it leads to increased memory usage, because compositing is the act of caching separate textures for certain DOM content. There is also some amount of unavoidable per-composited-layer overhead in our current system that slows down performance. We're working to improve that over time, but there is no free lunch. :) |
||
►
Sign in to add a comment |
||
Comment 1 by schenney@chromium.org
, Nov 3 2017Status: Available (was: Unconfirmed)
Summary: Position fixed/absolute layers jump when composited (was: Position fixed/absolute layers painting issues)