Issue metadata
Sign in to add a comment
|
(Regression) Elements with "will-change: transform" always render in initial scale if were animated with javascript
Reported by
iwasawa...@gmail.com,
Feb 15 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Example URL: https://jsfiddle.net/Iwasawafag/nk000606/1/ Steps to reproduce the problem: 1. Create an element, apply `will-change: transform;` to it from CSS. 2. Set initial scale to something smaller than 1. 3. Change scale from javascript by updating inline styles. Do it fast and/or often enough so browser would notice it's being animated 4. Observe render quality of the element once animation stopped What is the expected behavior? Render quality of the element should match resolution it's displayed in on the screen. What went wrong? It's not. It seems that browser fails to understand that animation has stopped or made significant progress and it's time to start repainting element in different scale. It then keeps rendering element in that resolution, even when child elements being added/removed. Clearing inline styles has no effect. The only thing that helps is moving element away from GPU layer (or whatever it called) by removing or updating `will-change`'s value. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 49, maybe 50. In early April of 2016 it was fine on stable release channel Does this work in other browsers? Yes Here's a test case https://jsfiddle.net/Iwasawafag/nk000606/1/ Chrome version: 56.0.2924.87 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0
,
Feb 16 2017
,
Feb 16 2017
This might be a dupe of an existing bug regarding a change in rasterisation behaviour that happened a while ago.
,
Feb 16 2017
Yes, I think this may be a dupe of issue 644012 (WontFix). +chrishtr to verify.
,
Feb 16 2017
Oh, it is indeed a duplicate. Didn't see that issue when searched for existing ones. Sorry. The document linked there (now https://developers.google.com/web/updates/2016/09/re-rastering-composite ) makes sense, but it was hard to find, especially until I figured out what caused this and what I should look for. MDN doesn't mention that Blink now implements will-change differently and there isn't many coverage on the web at all. In fact, I'm only able to find exactly one other article talking about it - https://greensock.com/will-change I guess there's no point in discussing the feature itself - it's been already decided and thought through. But I think, however, that you could have done a better job informing people about it. It would be great if some sort of warning was displayed in console, in the same fashion as deprecation of javascript features happen. After all, not many people actively follow change logs of every single browser and/or expect changes in "stable" features.
,
Feb 16 2017
Thanks for that feedback. I will try to update MDN soon to explain. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rtoy@chromium.org
, Feb 15 2017Status: Untriaged (was: Unconfirmed)