Jump to content
Search Community

"Bounce" released on iOS Safari when animation starts

badtant test
Moderator Tag

Recommended Posts

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.

Link to comment
Share on other sites

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

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

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!

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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 : rasterization-capture.gif

 

It is good to be aware of performance issues/pitfalls, on legacy browsers.

  • Like 3
Link to comment
Share on other sites

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

 

 

  • Like 2
Link to comment
Share on other sites

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...