Hey All,
Whenever I am turning a particle system off for the first time since loading the game, (the code snippet below specifically) I get a few dropped frames (like a quarter second of lag) on desktop but not on mobile. The CPU on the mini stats jumps from 3ish ms to 8 ms for a split second and then continues as normal.
let streakParticle = this.app.root.findByName("streakParticles").particlesystem;
if(this.streak >= this.streakThreshold){
streakParticle.play();
}
else {
if(streakParticle.isPlaying()){
streakParticle.stop();
}
}
Does anyone have any thoughts on this? To be clear it is when this line executes for the first time (but not subsequent times) since loading that I get the performance issue:
streakParticle.stop();
Hi @Jake_Johnson
So, I think that may be related to the particles system compiling the required shader the first time it’s enabled. On desktop and other supported devices the particles system uses GPU calc, whereas on mobile I think it mostly uses CPU. That would be explain why there is no compile time (dropped frames) on the GPU. @mvaligursky can comment if that’s the case here.
There aren’t much you can do, apart from turning on your particle system for a single frame when the app starts. So the compile time is being calculated there.
1 Like
I would suggest to profile it to see what is actually taking the time. I would not expect shader compilation when the effect is stopped.
1 Like
@mvaligursky All I am getting on the profiler is 2 orange marks on FPS whenever the dip occurs. I’m not exactly sure how to read it other than that.
@mvaligursky Oddly enough I don’t get the same jitter on Chrome, just safari and only on desktop. Because of this using the Chrome profiler doesn’t get me the data I need. I also noticed that on Chrome the mini stats include a GPU reading while on safari the mini stats do not. Does this mean that Chrome and mobile devices generally use the GPU while Safari does not on desktop?
Most mobile browsers and Safari do not expose WebGl extension allowing us to obtain performance timings on the GPU, and so we simply do not display them. But all still uses GPU.
If the issue only manifests on Safari, try using Safari javascript profiling tools then.
@mvaligursky Thanks for the info. It seems that stopping the particle system is causing a 93 ms garbage collection to happen which you can see below. If it is garbage collection I am assuming there is nothing to be done then? You can’t do your own garbage collection in Javascript can you?
There’s no control over the GC, other than allocating less. But it’s strange that it triggers it at the time you stop particle system … try using Pause instead of Stop to see if that makes a difference. Also, profile all this multiple times to confirm it’s just not a coincidence.
@mvaligursky After testing a bit, the lag occurs inconsistently (I’d say 75 percent of the time though I haven’t actually kept track) but when it does occur there is garbage collection. Sometimes Safari lists it as partial garbage collection and other times as full. Full is a more drastic spike.
I have tried using pause with a reset combined but it doesn’t fit my needs as I need the particles to die out naturally like the stop function provides.
