I’m busy doing some performance profiling on low-end devices, and wondered if anyone had stumbled across any tricks for squeezing out the best possible performance from Phaser? Any tricks like optimal fps, resolution, image sizes, etc.? Also, I’ve noticed quite a few Config settings (Phaser 3 API Documentation - Class: Config) and wondered if there might be some hidden magic bullets among them?
I’ve also done a bit of comparative testing with GotDot’s HTML export - Phaser’s CPU usage is about half, but GoDot seems to be doing something that make the perceptual performance seem better - no idea what though! (Might just be the right balance between fps and resolution?)
I guess there is antialias, antialiasGL, and scale.autoRound, but idk how significant they are nowadays. Rich usually recommends combining textures (atlases) or reducing game resolution.
Thanks guys! We’re currently running a whole bunch of performance tests and I’ll report back
@Parakul , what do you mean by “degraded images”? And how big is your atlas? We’re using Texture Packer but do have some massive background images, although none bigger than 4096x4096. Just testing at the moment what impact these have. Although I would have thought the impact would be more on memory or GPU, it does seem as if the CPU has to work harder to do… something… with huge images that degrades performance. Who knows what, but I’ll try and find out.
(Random vent: Getting usable metrics from Edge is a nigh impossible - it seems to throw 100% CPU usage at even the most basic Phaser/Pixi demos, but behind the scenes it then seems to have a hidden processing budget that it portions out as needed according to inscrutable rules…! )
Minor update: So removing our huge background images improved performance by 15fps. Odd, I would have thought that once the texture is in memory it should be stable? … Is there perhaps some way to tell WebGL that our backgrounds are static and be batched in the same draw calls… ?
@samme Thank you, fascinating idea that I’d never have thought of!
Interestingly, Rich suggested the same thing on Discord. He suspected the fps drop was simply due to the filtrate needed for those massive images - every pixel incurring needing to be drawn.
So we’re looking at splitting those big images into much smaller ones, and hiding/showing them when the scrolling into view - a kind of culling. (… is there any way to automate this Phaser…? For example, just telling it not to display sprites outside the visible viewport?)
Or, an invisible canvas that displays the background images as dom elements behind it. These background images are tightly integrated to the the game: scrolling, with a few layers of parallax. So I’m wondering, would adding these as sprites to Phaser’s dom container as dom sprites work as well as WebGL sprites? I’ve had a lot of success with dom sprites so far - definitely worth a shot!
@samme Thank you! That’s a great example, and the first working example of cull I’ve seen.
We tried it in our game and improves the average fps by 5. Reducing images to 1/4 their original size wins us another 5 fps. The other significant benefit to smaller images is that the game “warms up” much faster on start (by which I mean the time it takes for it to reach a stable fps is faster.) And, there are far fewer performance spikes (probably garbage collection) while playing. Culling alone seems to have no affect on improving those spikes.
Our background was generated and had a mask applied to the indivuel tiles That was bad performance haha. After applying one mask to the Container Terrain background that helped a lot.
Would be in favor of a Static Container, having no draw calls. Only on command.
… Is there perhaps some way to tell WebGL that our backgrounds are static and be batched in the same draw calls… ?