First play of animations freezes browser

[Stoffe]

At work, we've had an outsourced team create a game for us; they chose Phaser even though neither of us had any previous experience, but for the most part  that seems to have been a good choice - complete, good docs and examples etc.

But there is this one issue: on first play of animations, they freeze up. The team tried to solve it in what I think is a reasonable way - pre-play all the animations once during a loading screen. However, doing this is somehow so taxing that even simple CSS animations also freeze (multiple browsers, devices, operating systems) creating a jarring effect for the player. It also takes so much time - up to 5 seconds even on desktop computers - that just having a black screen also feels bad on many devices.

The thing is that it's not even that many animations, maybe 25-30 in all and most of them not that complicated. On one super powered graphics machine the freeze is down to less than half a second, but the machine itself does not even register it, meaning it's not (probably) a CPU issue or so, but something blocking maybe?

I've tried to search google, stackoverflow and these forums but I don't really find anyone else having this problem, which leads me to suspect that we are simply doing something wrong. The team is new to Phaser and I have myself not even written any games in it, though I can read the code. And frankly, them being outsourced makes them tend to declare things being "unfixable" a bit early at times...

I could post some code, but basically it's doing "world.create()" adding all the animations, and doing "play()".

Instead I would like to ask if there is a common/best practice or, otherwise if this is so weird that our animations must be broken from the start or any other reason you could think of. What exactly is Phaser doing on first play, is it unpacking the image to memory or something? Is this something that could be partly or wholly done beforehand in a build?

Would be very thankful for any clues - and I do apologize for the somewhat messy question, it's kinda hard asking third party questions.

Thanks!

 

 

 

 

 

[Zeterain]

It'd be hard to diagnose the problem without the code, but I understand that sharing it all might not really be an option.

If I understand: The animations freeze the game when they play through the first time, but afterwards, they play just fine.

Right?

Like you, I'd think it has to do with caching of some sort. But without playing with it, it's hard for me to tell.

Here's the documentation for Phaser.Animation.play() http://phaser.io/docs/2.4.4/Phaser.Animation.html#play

You can also go directly to the implementation of play: https://github.com/photonstorm/phaser/blob/v2.4.4/src/animation/Animation.js#L159

Sprites have a property on them called "animations" which is a reference to an animationManager. You might find clues there as well. Sorry I can't help more!

 

If you have a site where we can demo the game, that might also help. Touching the problem sometimes gives the opportunity for intuition to find an answer.

[Stoffe]

Yeah sorry, I know it's vague, but the code literally does not do anything more than calling "play()" as you refer to, above. The team noticed that first time animations played, they froze or stuttered, and so during init, just loop though them all and just do "play()" once for each.

This seems entirely reasonable to me, but has the adverse effect of freezing even simple CSS animations, giving a jarring effect on the loading screen instead.

Therefore my question, if people do this pre-warmup/caching in some other way that we just have missed somehow. If this is what people are usually doing, then it might be that our animations are somehow broken or heavy - looking at the implementation you linked may possibly help there, thanks! If someone does know what processing, if any, phaser does on first play() that could help, too.

Just trying to figure out which way to proceed - in fact, "no one else has this problem and we all just do warmup with play()" is also a useful answer because then it's something else on our side.

Thanks for the reply!