when scroll with high speed miss tweens

[GeorgeGeorgiev]

Hi,
when you scroll with high speed like scrollTo with the plugin of tweenMax for 1 sek it miss the tweens...
Here is the example : http://ag.sitetester.biz/indexscm.html . The superscrollarama do the same thing. I don't know why it miss some tweens.

[janpaepke]

Hi George,
Because there's so much happening on the demo page it's really hard to tell which ones are skipped and which ones not.
Can you please explain how to (possibly consistently) reproduce the error?
Even better would be to create a jsfiddle just showcasing the problem with as little code and elements as possible.

My suspicion is that it is the same problem as in these issues: #92 and #97

But as of yet I do not have any proper environment to reproduce and debug it.

[GeorgeGeorgiev]

Hi Janpaepke,

ok i will try to make a jsfiddle with all the code except my custom plugins. You can reproduce the error when click on the lowest section of the right navigation and when the scrolling is done click on the topest section of the navigation. You will see that thte sections are overlaping so some of the tweens which has opacity:0 was not triggered. If you extend the time to scrolling from the navigation to 10 sek it has normalize but sometime it has a issues with the same thing which i have writed above.

[GeorgeGeorgiev]

Hi Janpaepke,

here is one fiddle for experiment with :

http://jsfiddle.net/GeorgeGeorgiev/56owtpf8/

It is not perfekt but you will see that it remakes the issue if you scroll down fast from the right menu and again scroll up with the right menu for 1 sek it overlaps some of the texts.

[GeorgeGeorgiev]

Here is close copy:

http://jsfiddle.net/GeorgeGeorgiev/56owtpf8/2/

[GeorgeGeorgiev]

You can put onupdate on the scrollto event console.log to see how munch steps does it make.

[GeorgeGeorgiev]

Ahh sorry for such a spamm but i want to make your job easier. Here is the full window view:

http://jsfiddle.net/GeorgeGeorgiev/56owtpf8/2/embedded/result/

[GeorgeGeorgiev]

You are right the 92 and 97 are the same things i have search trough one of the sites and it makes the same thing http://kingofthehill.esfxtv.com/ . So the easiest way to reproduce the bug is enter on the site wait all the js to load and click on the end button then click on the home button you will see how the elements are missed the tween to hide them. See the same on my site. Click End button and then home. This is not from the other scripts.

[janpaepke]

So I did some research on the matter.

1. There is no problem if the tweens concern different elements: http://jsfiddle.net/janpaepke/sn04juhp/
2. The same if the scenes have a duration: http://jsfiddle.net/janpaepke/sn04juhp/1/
3. It also works if multiple tweens change different parameters on the same element: http://jsfiddle.net/janpaepke/sn04juhp/2/
4. This is where things get messy. This fiddle moves the same block right, then left, then right and then back left: http://jsfiddle.net/janpaepke/sn04juhp/3/
   However it only works as expected, if you scroll very slowly.
   The faster you scroll, the more likely to break out of the desired pattern.
   Sometimes the square is on the wrong side, sometimes it's even stuck in the middle.
   The same goes for scenes with duration even though they at least fix themselves after showing the wrong position.

So here's the problem: because all scene's get triggered at once, all tweens are started at the same time. It's really difficult to tell which has precedence over the other. The reason is that Scenes can be added in random order and their starting position can change at any time.
So how to tell which is the last one in order and should be the one played?

I experimented with the overwrite option of TweenMax without any success.
Then I tried to create an example That just uses GSAP and no ScrollMagic.
In this fiddle: http://jsfiddle.net/janpaepke/sn04juhp/13/ all tweens are triggered at the same time and you see a small jump when playing the tweens. When hitting reverse it will cause the box to move to that position.
I will write to one of the guys over at GreenSock and ask them to have a look. I'm sure they can explain.
Note: ScrollMagic wraps all tweens in a TimelineMax object to include delay and repeats in the duration and standardize methods.

As for the imminent problem I have found a solution that only works when the scene has a duration:
http://jsfiddle.net/janpaepke/sn04juhp/5/
I wrapped all Tweens in a Timeline and it works, because the order in which they are supposed to be triggered is clear.
Obviously this is not a good solution for the times you want to fade in an element at the top of the page and fade it out at the bottom.

At the moment I am at a loss as to how to address this issue.
I would kind of have to check if multiple scenes with tweens that have conflicting parameters are triggered at the same time. Then I'd have to decide which of them has precedence (i.e. which trigger point would be the first or last) and the animation of this particular parameter for this particular tween.
So my questions to all or specifically to the Greensock guys:

• Is there a better way to do it?
• I could collect property overlapping scenes in the update cycle (to then decide which one has precedence). I'm afraid this will cost performance - can you think of another situation though?
• Is it even possible to temporarily deactivate one property or give precedence to a certain propery in a certain tween?
• Or do I need to construct a new tween that overwrites the others?

Any notes and suggestions are highly appreciated.

[GeorgeGeorgiev]

Hi jan. I have worked a lot with these too and make the same things. The overwrite property can make a difference but only in the one way :) So if you scroll back somewhere will be broke again. So for now the best way to work around is to have multiple DOM objects on one object :) To say the DOM structure of the elements is div#1>div#2 and you call first on the div#1 opacity:1 then you call on the div#2 the opacity:2. It this work around we can make a bypass for now. So see the result :

http://ag.sitetester.biz/indexin.html

Also i have tryed to kill the tweens great mistake ... It kills them and never fire again :)

[janpaepke]

Well what I meant in #134 was to kill all and then fire only one tween (the appropriate one) whenever a scene is triggered.
But I realize now this will have the same problem, albeit working slightly better: http://jsfiddle.net/janpaepke/sn04juhp/7

Your suggestion to use different objects does work, but of course is rather dirty and only works with opacity tweens. There has to be a better, more universal solution.

I made a new version of the fiddle, that always checks for the tween with the highest precedence
http://jsfiddle.net/janpaepke/sn04juhp/8 (also mind the console log)
As far as I can tell It works and the behaviour is as expected but has two drawbacks, one small one big:

1. (small) The first and last animation will always run, even though the target position might be the same. The reason is that the tweens that shouldn't be played still need their progress to be updated to enable them to play and reverse correctly on future triggers. This could be solved if there was a way to update the tween progress without triggering a render, which to my knowledge there isn't.
2. (big) The bigger drawback of this method is that the Tween with the highest precedence will always win, regardless of the tweened parameters. So if not all parameters are overlapping or are different alltogether the script wouldn't care and skip all to completion apart from the one with the highest precedence.
   This makes this approach practically unusable apart from single application workarounds.

I think the best solution would be this:

• ScrollMagic should be responsible for calling the tweens in the right order.
• GSAP should be responsible to make sure that the last called tween should always override tweens with conflicting parameters, when starting multiple tweens at the same time (same tick).

This however does currently not work as expected with GSAP. I have created another example that again doesn't use ScrollMagic, but just mimics the way the tweens would be called by ScrollMagic.
http://jsfiddle.net/janpaepke/sn04juhp/11
When firing multiple tweens the box jerks for a bit and the tweens somehow get broken.
Logging their progress (use button) shows weird numbers.
I noticed this is sporadic, so if it doesn't happen for you, reload and try again.
When reversing the tweens in reverse order the outcome is again unexpected.
It should stop at the left position but instead stops somewhere else.
From now on the logged progress seems correct after every play or reverse, but the positioning is off. I tried to see if adding delays changes anything, without success...

So I guess this is as far as I can take this – I'll need some input from the GSAP folks now.

[jackdoyle]

From what I can tell, this is all expected behavior, but I can see why some if it appears odd or cryptic. Let me explain...

Summary of how "auto" overwriting works:
The first time a tween renders, it looks for active tweens of the same target(s). If it finds any, it analyzes individual tweening properties and if it finds any, it kills just those individual overlapping properties in the previously active tween, and if there are no longer any properties left in that particular tween, it kills the tween itself (no use keeping that around and wasting resources to tween nothing).

Why were there weird progress values?
Because all the first 3 tweens got killed after their first render, and the 4th stayed alive. Here's the process:

1. Tween 1 started, found no overlapping active tweens.
2. Tween 2 started, found Tween 1 that was overlapping, killed its "left" property, and since there were no tweening properties left active, it killed Tween 1 completely, thus halting its progress.
3. Tween 3 started, found Tween 2, and did all the same stuff to that (killed "left" property and the entire tween, halting its progress)
4. Tween 4 started, found Tween 3, killed all that stuff, and then completed as expected.

So as expected, the progress of Tween 4 made it all the way to 1, whereas the progress of the first 3 tweens got halted after their first render.

In what order will tweens render?
In the order they're created, or if you place them in a timeline, they'll always render according to their scheduled time of execution and if you place two tweens at exactly the same spot on the timeline, they render in the order in which they were added.

How can I prevent overwriting?
If you want to avoid overwriting altogether, simply add this one line of code first:

TweenLite.defaultOverwrite = false;

Just remember, overwrite management is a unique feature of GSAP that is intended to help you and in most situations, it prevents unintended behavior by protecting you from conflicts that you created in your code. However, in this situation, since ScrollMagic wants/needs total control over everything and intends to take responsibility for managing things properly, it's fine to disable the built-in overwrite:"auto" behavior.

You can also prevent an individual tween from overwriting others by setting overwrite:false in its vars/config object.

Also, paused tweens are immune from overwriting, so you can use that as a management tool if you want. In other words, if you've got 4 tweens of the same object's properties, you can pause() them all and just play() the one you want.

Why didn't all the tweens reverse() the way I expected?
Because all but the last one had been killed.

Why did things render a little differently each time I reloaded?
It all depends on the browser's rendering cycles and how much time elapses between when the tweens are created and when they render for the first time. In the example, all of the tweens had a duration of 0.2 seconds which is pretty short, and the first tween was animating "left" to 200, meaning it's moving at 1000px per second. Typically the browser will try to render frames at 60fps, meaning every 16.7 milliseconds, but that's not guaranteed. It may take 20ms sometimes, or 42ms or whatever. GSAP always renders things EXACTLY where they should be at that particular time (whenever the render happens). So if the first tick took 20ms, Tween 1 would render at left:4. If it took 50ms, it'd render at left:10, etc. Then, Tween 2 would start and treat whatever left is at that point as the starting value, and if 50ms had elapsed and left should end at 0 for that tween, it'd render it correctly at 9.5. Then, Tween 3 would do its calculation, treating 9.5 as the starting value and 200 as the end, thus render it at 19.025. And so on.

If the next time you reload, the browser happens to execute that tick faster, at 18ms, you'd see those values change accordingly. Again, that's exactly what GSAP should be doing.

Summary
To get the behavior you're asking for (if I understand you correctly), just change the default overwrite mode to false and then you can take responsibility for managing things instead of letting GSAP's logic dictate things. Alternatively, you can pause() and play() things as you please because pausing shields tweens from being overwritten.

Does that answer your questions adequately?