badtant Posted August 27, 2020 Share Posted August 27, 2020 Hi! I'm not sure if this is a gsap issue or not but hopefully someone here has insights. So, I have a 100% height container that contains my content and scrolls. It also has -webkit-overflow-scrolling: touch set to get smooth scroll on iOS. In the container I have a gsap animation that runs with an interval (yes, I could use loop but my real case contains random numbers for each time it runs). To reproduce the issue (on an iOS device or simulator): 1. Scroll the container to one end so that you get the iOS "bounce" thing and hold it there 2. When an animation starts, the bounce is "released" and I don't want that Here is a JSFiddle: https://jsfiddle.net/oxeys91u/41/ You can view it (on an iOS device or simulator) here: https://jsfiddle.net/oxeys91u/41/show I've also attached a little movie showing the issue. ios-bounce.mov Link to comment Share on other sites More sharing options...
ZachSaucier Posted August 27, 2020 Share Posted August 27, 2020 Hey badtant. 5 hours ago, badtant said: In the container I have a gsap animation that runs with an interval (yes, I could use loop but my real case contains random numbers for each time it runs). I'd use GSAP's .delayedCall() 5 hours ago, badtant said: I'm not sure if this is a gsap issue or not but hopefully someone here has insights. A very test-able question! Replace the tween with just boxRef.current.style.transform = `translateX(${gsap.utils.random(0, 100)}px)`; (or any other translation). The problem still occurs, thus it's not due to GSAP. I am guessing there's nothing you can do about this. But that's a guess Maybe someone can figure out a work around. Unfortunately since it's not due to GSAP we can't spend a bunch of time trying out possible solutions. Link to comment Share on other sites More sharing options...
badtant Posted August 27, 2020 Author Share Posted August 27, 2020 I tried that and yes, the problem still occurs. I also tried with a css only animation and when doing that the problem disappears. So I'm guessing this has something to do with repaints caused by setting transforms with inline style? And yes, then it's probably not specific to gsap but to animations done that way. Any pointers in any direction how to tackle this is appreciated. I want to keep doing the animation with gsap Below is the css only animation that didn't have the problem. @keyframes test { from { transform: translateX(0); } to { transform: translateX(100px); } } .box { width: 100px; height: 100px; background: red; animation-name: test; animation-duration: 0.5s; animation-iteration-count: infinite; } Link to comment Share on other sites More sharing options...
elegantseagulls Posted August 27, 2020 Share Posted August 27, 2020 Hi @badtant, The only (untested) way I could think to get around this could be to try tweening a css custom property that's tied to your transform value. .box { --transform-val: 0; transform: translateX(var(--transform-val)); } gsap.to('.box', {'--transform-val': 100 }); And if that doesn't work on the.box element, try setting that tween/var on the body or :root, or another ancestor element that may not cause a repaint. Good luck! 1 Link to comment Share on other sites More sharing options...
badtant Posted August 27, 2020 Author Share Posted August 27, 2020 With some googling I ended up on an article about the css property will-change. If I set will-change: transform; to .box the issue seems to go away. You can also set will-change: opacity; or both will-change: transform, opacity; I added an opacity/autoAlpha animation to my box but will-change didn't seem to solve that one. Anyone used this before?https://developer.mozilla.org/en-US/docs/Web/CSS/will-change 1 Link to comment Share on other sites More sharing options...
elegantseagulls Posted August 27, 2020 Share Posted August 27, 2020 Good to know! I use will-change a fair bit, depending on project/scenario. You just have to be mindful of overusing it. It's similar to the 3d transform / translateZ hack to gain hardware acceleration to avoid re-paints. Thanks for the solution follow-up! Link to comment Share on other sites More sharing options...
PointC Posted August 27, 2020 Share Posted August 27, 2020 There's a post on the GS blog about it too. 2 Link to comment Share on other sites More sharing options...
elegantseagulls Posted August 27, 2020 Share Posted August 27, 2020 50 minutes ago, PointC said: There a post on the GS blog about it too. Ah yes, however, the info there is a tad outdated. The will-change browser support/usage/performance has gotten much better. Just compare: See the Pen d454214493bbc4d4dc1d6fb9b734d1e8 by GreenSock (@GreenSock) on CodePen to the old way browser handled it : It is good to be aware of performance issues/pitfalls, on legacy browsers. 3 Link to comment Share on other sites More sharing options...
PointC Posted August 27, 2020 Share Posted August 27, 2020 Sounds like it may be time for a post update. Nice of you to volunteer @elegantseagulls 2 Link to comment Share on other sites More sharing options...
ZachSaucier Posted August 28, 2020 Share Posted August 28, 2020 Ya, it's fine to use will-change within reason these days. But make sure to do testing across different browsers and devices as it's still not error-free. 1 Link to comment Share on other sites More sharing options...
OSUblake Posted August 28, 2020 Share Posted August 28, 2020 Using will-change is fine. Articles warning about it are to prevent people from doing stupid stuff like this. * { will-change: transform; } Will change creates a bitmap of the element for faster rendering. The only issue with that is scaling. Choose your poison. See the Pen 6ed5cf3966861e68ac0d4e7a47c17847 by osublake (@osublake) on CodePen 2 Link to comment Share on other sites More sharing options...
elegantseagulls Posted August 28, 2020 Share Posted August 28, 2020 5 hours ago, OSUblake said: Will change creates a bitmap of the element for faster rendering. The only issue with that is scaling. Choose your poison. This looks great in Firefox, but, alas, not Chrome. Because of this, I find that it's best to set the element to initially render at max scale size, then set transforms/scales from there. Link to comment Share on other sites More sharing options...
OSUblake Posted August 28, 2020 Share Posted August 28, 2020 It looks like firefox doesn't rasterize scale. It shows paint flashing. 2 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