How to detect when an asset is added to the screen?

[Manifest]

When I add a sprite to the screen there is often a sizeable delay before it appears, especially if it's on mobile and it's a large sprite(sheet). I've seen upwards of 800ms delay per sprite on some mobile devices. This delay seems to be the initial tex2D draw call, where I suspect it uncompresses the image or caches it or something similar - subsequent appearances of the same sprite do not have the same long delay. Note: I have a loading screen where the asset is loaded into the Phaser.game.cache already, so that is not occurring during gameplay.

 

This is causing me to run into issues when I want to animate something immediately upon adding it to the screen. My code should behave roughly like:

1. Add sprite to screen
2. Sprite gets added to screen
3. Animate sprite with initial appearance animation (~ 1 second duration)

But instead, due to the appearance delay, it works something like:

1. Add sprite to screen
2. sprite.animations.play()
3. *DELAY*
4. Sprite finally visible onscreen, no animation plays (sprite remains in frame 0)

It's as though the sprite "misses" the animations.play() call as it hasn't finished caching or whatever it's doing. What I really want to do is something like:

1. Add sprite to screen
2. sprite.events.onActuallyLoadedForReal.addOnce(() => sprite.animations.play());

To mitigate the problem, I have tried:

1. Saving the sprite as an uncompressed .png to cut down on delay time
2. Preloading the sprite i.e. showing it on the main menu where interaction is not critical
3. Putting in a Phaser.Timer before I call animations.play() and hoping that it has finished 

Options 2 & 3 prevent the issue, but are not ideal solutions. my question is basically: is there a better way to do this, or is there a way that events.onActuallyLoadedForReal could actually be listened for?

[rich]

Hmm I've never seen this happen before, but I guess it may take a while to upload to the GPU - 800ms seems ridiculously excessive though, even for a really slow GPU. Here's a thought - after your preloader, why not create a sprite using the texture then? Set alpha to 0 or something so it doesn't render, or hide it off-screen, but at least the texture will then be on the GPU. Needless to say there is no event you could ever listen to in order to find out when this happens, because it's impossible for JavaScript to know when a texture is on the GPU or not.

[Manifest]

Thanks rich, yeah, I suspected there would be no way to tell. I'm currently using the approach you suggested and trying to hide the lag spikes on screens where smooth framerate isn't a priority, but it's not ideal.

[rich]

Just to reiterate - I've never seen what you're describing happen, not across loads of testing devices and different frameworks - which makes me wonder just how large your sprite sheets are, and how flooded the GPU memory has become.

[Manifest]

The spritesheets are around 2500x2500px, uncompressed they make up about 92MB total. Nexus 10 is one of our target devices, so high resolution is a priority.

[rich]

Wow, that's a lot of data. 92MB uncompressed, you mean actual GPU RAM size, or just uncompressed file size?

[Manifest]

Just uncompressed filesize. Yeah, it's a lot =/ 

[rich]

Blimey, that must be hundreds of MB of actual GPU ram. I wonder how much is even made available to the browser on a Nexus 10, once the OS and other running apps and tabs have taken their slice.

[richpixel]

Btw I'm also dealing with a similar issue - I load my assets and show a background image of 768x1104 (usually cropped height).

 

Then I put a single animated sprite on top and the first few frames chug at a low frame rate before it 'catches' and starts playing smoothly. I only see the issue on slower/older devices like iPhone 4. However, the issue goes away if I don't show the background image. I figure there is some way to juggle this where you display sprites initally offscreen or hidden in some way to ensure textures are in the GPU before I really need them. Still investigating.