Share Posted March 21, 2016 Hi, I've no link to the Chrome Bug Report yet - I used the above as an example - so I can only assume it's not been responded to yet. Try this >> http://dev.andyfoulds.co.uk/asdasd , rollover the buttons at the bottom. It was silky smooth in Chrome 48. I have a Win7 PC with an NVidia graphics card but I've also seen this on my Mac at the studio, even got to see it before-and-after as Chrome updated itself! Andy___F Link to comment Share on other sites More sharing options...
Share Posted March 21, 2016 Thanks for the additional info NDF Link to comment Share on other sites More sharing options...
Share Posted March 22, 2016 OK Fellow GreenSockers, Here is the Chrome bug report for this new Chrome 49 flicker pixel-snapping: https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= The more people comment on this behavior in that bug report. The faster the Chrome Dev Team can fix this. I just left my comment in detail describing the behavior. But they didn't know that it is being caused by Nvidia and Intel graphics cards. When leaving your comment make sure you leave the following and any other additional examples if you have them. You need to have a Google account to sign in and leave a comment on this Chrome bug issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= OS OS Version What graphics card (Nvidia or Intel) you tested in Chrome 49. (make sure they know this) Any additional examples showing this behavior. Carl's code example is being used to describe this behavior. AMD Radeon graphics cards seems to be working fine. Hopefully the more info they have regarding this flicker bug, the faster they can fix it. 2 Link to comment Share on other sites More sharing options...
Share Posted March 22, 2016 What about IE and Edge? They have the same problem. EDIT: And I see you posted about that somewhere else. There's too many of these topics open right now. Can we lock the other ones down? I'll let you decide 2 Link to comment Share on other sites More sharing options...
Share Posted March 22, 2016 Ok i just locked this other topic and pointed others to this topic, since it has Carl's codepen example and YouTube video showing this behavior. I forgot to include MS Edge, and they don't have an edit comment feature on that bug report tracker. On a side note regarding MS Edge. The bad thing about MS Edge is that it allows webkit prefixes and renders like webkit. I have a feeling that the issue in MS Edge and IE can be fixed with a slight rotation:0.01 .. i tried this on a computer with Nvidia graphics card in MS Edge using See the Pen rexpMG?editors=1000 by GreenSock (@GreenSock) on CodePen , and i no longer saw the pixel-snapping flicker with a slight rotation. Thanks Blake! 2 Link to comment Share on other sites More sharing options...
Share Posted March 22, 2016 Great work, Jonathan. I just posted on the bug report with a new demo that does NOT use GSAP (just RAF) http://codepen.io/anon/pen/LNyYrX and a video (watch at full size) anyone else, please "star" this issue that Jonathan created: https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= 1 Link to comment Share on other sites More sharing options...
Share Posted March 24, 2016 please star this topic if you haven't already https://bugs.chromium.org/p/chromium/issues/detail?id=596382 Link to comment Share on other sites More sharing options...
Share Posted April 11, 2016 Thanks to everybody who put these janky demos together and explained the issues that this bug is causing to the Chrome team. I build sites (like this one) with ScrollMagic + GSAP scale tweens, both of which make me look like a champion to my non-techy clients. Smooth scaling is muy importante to me, both in the background (Ken Burns FX, etc) and the foreground (clients want pop; scale pops). This bug came around and screwed that allll up. I've starred the issue and I hope that my clients are using other browsers (or have good graphics cards) until a fix comes though. Blagh, Dave Bloom Link to comment Share on other sites More sharing options...
Share Posted April 13, 2016 Chrome 50.0.2661.75 and still janky. Link to comment Share on other sites More sharing options...
Share Posted April 13, 2016 Hello Oliver15Years if you follow that Chrome bug report for this issue. The Chrone Dev Team is still working on the issue, since it is intwined with previous scale bug reports.https://bugs.chromium.org/p/chromium/issues/detail?id=596382So we just have to be patient, normally this bug would be a Won't Fix, but since we hounded the Chrome Dev Team to death regarding this issue, we got their feet moving 1 Link to comment Share on other sites More sharing options...
Share Posted April 14, 2016 Appreciate the hounding. I think the key was to mention how well Safari and Firefox perform in comparison, so thanks Carl! DB Link to comment Share on other sites More sharing options...
Share Posted April 14, 2016 Appreciate the hounding. I think the key was to mention how well Safari and Firefox perform in comparison, so thanks Carl! DB Haha! Even better, tell them IE 8 next time. 2 Link to comment Share on other sites More sharing options...
Share Posted April 21, 2016 This Chrome 49 Jank Bug is now achieved FIXED status: https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= If everyone can try out the previous examples and it should behave without jank, jitter or pixel-snapping! Thanks to all that voted up this Chrome bug ticket 1 Link to comment Share on other sites More sharing options...
Share Posted April 21, 2016 Best email I've gotten all day. Thanks everyone! DB Link to comment Share on other sites More sharing options...
Share Posted April 21, 2016 i just checked my demos in 50 and they look great. YES! Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 The Janky zoom is back!!! Chrome 53.0.2785.116 Win7 See the Pen rexpMG by GreenSock (@GreenSock) on CodePen I DON'T BELEIVE THIS! Frustrating. I have a few running campaigns with zooms in them. 1 Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 Thanks for reporting this Oliver15Years It looks like this is related to this on going webkit chrome bug found here: https://bugs.chromium.org/p/chromium/issues/detail?id=521364 But I'm under the impression that that this bug is back being triggered by something else that they added in Chrome 53, since the above is for text and not background-image. even though this bug can affect both text and background images. https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= 1 Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 They give this solution:https://docs.google.com/document/d/1f8WS99F9GORWP_m74l_JfsTHgCrHkbEorHYu72D4Xag/edit Put will-change: transform;in the CSS, but is is making the entire image low rez. Update:My friend tried everything with everything. This is working: -webkit-transform: translateZ(0); will-change: transform; Update:This will cause megablurriness on elements whose are zoomed from smaller to bigger scale. 1 Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 Be careful with will-change CSS property it should only be used as a last resort. And last time i checked last week, will-change was causing other weird behavior causing massive blurry pixelation on elements. Kind of like a offset Gaussian blur in Chrome.. having the opposite effect. This looks like it works, but it can add other performance and blurriness, so use it at your own risk This bug still needs Chromes attention since will-change is a last resort but good find! 1 Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 You are right Jonathan. I see now this is not the solution. I give up and will bring this issue to my client's attention. Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 Any idea why will-change is to be used so sparingly? They used to say that about fats on the food pyramid, but I tried eating 6 baguettes a day and didn't lose my love handles. Is it bad for a single instance of animation performance, does it affect load times, or repaints..? DB Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 Looks like Google Devs replied and suggested will-change.. which is weird their solution is to use a last resort css property to fix a chrome bug. very weird So now you have to create a rendering layer with will-change for any scaled text or images. So not even doing a 2D transform scale and you have to deal with this chrome bug. What happens if your scaling multiple elements.. all elements will need will-change and cause some blur on elements that don't need will change. The best way is to apply will-change is with JS so its not used on the element at all times. But this looks like it needs to be on or set before page load to work properly. Some of the Chrome Devs don't even consider a bug yet other browsers like Firefox IE, Edge, and Safari don't have this buggy jitter or blur. But looks like they consider it normal behavior based on the latest replies to that bug report. How is this not a bug? There might be hope that this will be fixed after further discussionhttps://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 Really shameful that we have to look for a workaround from time to time, when they are coming out with a new version, mess up things that's usually working. We've tried out a few things with and he was right, using "will-change" will pre-cache the pixel asset. So scaling an asset from <1 to 1 will make it pixelated. Setting this to the asset container seems to fix the problem. TweenLite.set ( [container] , {webkitPerspective: 1000}); 1 Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 transform: perspective() CSS function or perspective property used to fix this bug around Chrome version 20, but that has been on and off working to fix it. Then it started with elements scaled above a scale factor of 1 would be blurry. In every Chrome version the previous fix stops working. Just like we are seeing with this old new WebKit blur jitter bug. Fun stuff Link to comment Share on other sites More sharing options...
Share Posted September 19, 2016 Now I'm seeing the jitter on scaling - can we do what we did last time and inform them that the competition seems to have a better handle on things? That seemed to light the right fire.... Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now