PIXI.Graphics.renderWebGL / renderGraphic - performance problems - SOS!

[ForgeableSum]

I'm pretty much at my wit's end hear. Thus I am resorting to an SOS forum post. 

I've encountered a very strange performance bug. It's more or less untraceable because it is caused by a bunch of internal calls made by phaser and pixi. This is the culprit (according to the chrome performance profiler):

This happens every 20 seconds or so. A massive FPS drop with several animation frames hanging on PIXI.WebGLRenderer.render.

I've gone to great lengths to identify the root cause, including putting a return statement at all of my core functions, monitoring performance, and seeing if the problem is still there. But I can't seem to find the cause as the problem goes away and comes back unpredictably. 

What I'm hoping for is some sort of explanation as to what Pixi is doing here. Is this related to Phaser.Graphics? What would be a common cause of phaser needing to call updateRender so many times in just a few animation frames?

I realize this is a long shot. Any insight would be helpful. 

 

[Fenopiù]

When I've had a very similar issue, it was for Phaser.Text and webfonts.

When it had to load several text with webfont (in local) FPS was flop and immediately raise back.

[ForgeableSum]

I've removed all instances of Phaser.Text and any webfonts. I'm afraid the problem still persists. 

 

[ForgeableSum]

if i put a return statement below PIXI.Graphics.prototype._renderWebGL = function(renderSession) - the problem goes away so i know it's that.
i put a statement in there to trace which graphics is causing the problem, i.e.
if(game.time.fps < 40) {
    console.log(this);
    } in PIXI.Graphics.prototype._renderWebGL

here's what's so bizarre. i identify the graphic which causes the problem based on its world position, etc. then i remove the graphic entirely and try again what happens is that another separate graphic will cause the FPS drop. which leads me to believe that any presence of a Phaser.Graphics - regardless of what I do with it, causes the problem. How can this be?

[ForgeableSum]

well, i can confirm that it is in fact phaser graphics that are causing the problem. The problem is that it's not any one graphic. If I set ALL graphics (there are 10 total) to visible = false, the problem goes away. But setting any 1 graphic not visible, with the rest visible, does not cause the problem to stop. 

I can honestly say that I've never seen a bug like this before. 

[Fenopiù]

Wow... that's a really big bug! O_o

What Phaser version do you use?

[ForgeableSum]

2.6.2 though I've tested it and found the bug appearing in the latest community edition. 

[ForgeableSum]

And yes, it makes no sense. I've dismantled my game dozens of times now trying to find the cause. I'm beginning to question reality. I can't sleep at night! 

[ForgeableSum]

Another week of trouble-shooting. Still, no luck. 

[rich]

What is the Graphics object? I.e. what are you rendering with Graphics? A simple rect, lines, circles, etc? How complex is the shape? Because it doesn't take much before Pixi will flip over to using the stencil buffer to render the graphics, and I'd put money on this being part of the cause of the issue.

[ForgeableSum]

2 hours ago, rich said:

What is the Graphics object? I.e. what are you rendering with Graphics? A simple rect, lines, circles, etc? How complex is the shape? Because it doesn't take much before Pixi will flip over to using the stencil buffer to render the graphics, and I'd put money on this being part of the cause of the issue.

It's about 40 rectangles to one graphics object (the healthbars), 20 circles (unit circles underneath) to a separate graphics object and another 20 rectangles to a separate graphics object (the mini map) all at around the same time.

All in all, it doesn't seem like that much. I'm doing the same graphics stuff in strike tactics and it never gives  a stutter problem.  

[ForgeableSum]

Also, if I remove 2/3rd of all the graphics activity i outlined above (e.g. disable unit circle and healthbar updates), the problem persists). It seems like having any small quantity of graphics updates causes the problem. 

It also happens if I remove updates to the mini map. So it's like the mere existence of graphics causes the problem. 

[ForgeableSum]

Okay, i just ran an interesting test. 

If I remove ALL updates to graphics objects, the stutter is gone. But if I leave in even a single update (e.g. drawing a single rect and clearing it every tick), the problem is just as bad as drawing hundreds of rects. Again we're talking about drawing a single rectangle to a single graphic. And the stutter is monstrous!  

If I set all graphics to not visible, the problem goes away (regardless of how much I update them). 

I also tried limiting the number of graphicsData pushed to 10 (to assure it wasn't the quantity of graphics data) and it had no effect. 

[Sky Alpha]

I faced the Same issue creating an RTS Game.

HealthBar -  Graphics Line for every Unit representing the health.

Selection Circle - Using Phaser Circle to show the selected Unit.

I kept them Hidden while the unit where not selected. And when I Selected a couple units the game instantly Dropped 20FPS, just for having the Units selected.

I ended up removing all those graphics and substituted them for Sprites. For my HeatlBar I used a White Blank Sprite with the Height of my health bar. then I would Tint it with the color of the current HP. And for the Selection Circle I used the same approach, a circle Sprite, scaled to my Unit size.

I Instantly got back to 60FPs even with A lot of Selected Units.

I learned on this thar I always have to use Sprites, when ever I can. They are much faster. I Hope this helps others.

Cheers.