Surprising tween timing in 2.4.4

[zekoff]

Summary: in Phaser 2.4.4, there is a huge delta between a tween that takes n seconds, and n seconds of physicsElapsed time. A small delta exists in 2.4.3, but the 2.4.4 delta is an order of magnitude higher in some cases.

 

Here's a jsFiddle to reproduce the issue.

Run it a few times with 2.4.4 (already loaded) and check out the delta times. Then, substitute the 2.4.3 version and try again.

 

Here are some examples with 2.4.4. This is the result of five runs in a row:

 

And here are some examples with 2.4.3. This is the result of five runs in a row:

 

Additional information:

• Sometimes, 2.4.4 will have very tiny deltas -- I've seen as low as 1, 16, and 17ms. Every time this has happened, it's been the first run after a page refresh. Most of the time, though, 2.4.4 is between 2000 and 2500ms. 2.4.3 is more consistent, usually between 250 and 400ms.
• 2.4.4 usually has the tween finishing much slower than the physicsElapsed timer, so the delta is how much longer the tween ran. However, on my old and busted desktop, the opposite was happening for a while: the tween would finish much faster than the physicsElapsed timer. This occurred in the game in which I discovered the bug, and I wasn't able to reproduce it with the jsFiddle. I promise it happened, though.
• Here's a recent issue report that seems like it might be related, but I'm not cognizant of the history of this bug so I can't be sure.

So, my questions:

1. What changed in 2.4.4 that would have contributed to this?
2. Even in 2.4.3, the delta is bigger than I would have expected. I understand that a non-frame-based tween uses time.elapsedMS, not time.physicsElapsedMS (here's the relevant line), but I'm still surprised to get deltas even as high as 250ms.

[Skeptron]

It works well with game.time.elapsedMS. My guess is that this "bug" comes from a bad understanding of what physicsElapsed really is. If you look at the documentation, it's a fixed number which by no way is influenced by the FPS slight variations that may occur during a real-life simulation.

 

Also, you can add game.forceSingleUpdate = true; at the beginning of your create() method and see great improvement in the deltas.

[Skeptron]

Forgot to link the relevant doc section : https://github.com/photonstorm/phaser/blob/v2.4.4/src/time/Time.js#L112

[zekoff]

Good call on physicsElapsed, and thanks for the link. You taught me something new.

 

Still, this doesn't fully explain why a tween that's set to last 5 seconds lasts much longer. If you don't mind taking another look at the examples in the first post (ignoring the physicsElapsed and the delta, since I just ended up muddling this issue with those), you'll notice that the time the tween ends is much more than the 5000ms after the time the tween starts. Those times are generated with Date.now(), so they aren't Phaser-related at all. They should be as close to real-time as the browser will allow.

 

For example, in the first 2.4.4 example above:

Start time is 1445814667358

Tween finishes at 1445814674860

Leaving 7502ms between the Date.now() call when the tween started and the Date.now() call when the tween finished.

 

Here's an updated jsFiddle with all of the physicsElapsed stuff removed:

http://jsfiddle.net/xbhaywtk/4/

 

And here are a few runs from this new code, again using nothing but a 5-second tween and Date.now(). Needless to say, all of these should end up very close to 5000ms, if I understand correctly:

 

Here, the tween takes 6800ms to run.

 

Here's, it's 6932ms.

 

And here's a third try that takes 7360ms to run.

 

Since physicsElapsed is completely out of the equation this time, what gives?

[Skeptron]

I think you're doing your test wrong. You should not assume the tween will start right after you call the tween.start() function : instead, you should use the callback method onStart.

 

Using that, forceSingleUpdate and disableVisibilityChange (we never know, game might pause if you click away), I got much better results. Not perfect though.

 

JSFiddle : http://jsfiddle.net/xbhaywtk/5/

[zekoff]

Wow... I'm getting much better results with those updates. Thanks for the info.

 

So, based on this test, the real delay is not in how long the tween runs but in how long it takes to start after you tell it to via tween.start(). Do you have any insight into why that's the case? That's still surprising behavior.

[Skeptron]

I honestly don't know. Could be 1000 different reasons : the tweenManager may instantiate objects, wait for processes to end... You could have a look at the code yourself : https://github.com/photonstorm/phaser/blob/v2.4.4/src/tween/Tween.js#L283