Sprite batching causes GC pauses

[davedx]

Hey guys,

We saw some behaviour yesterday when working with sprite batching that led us to believe the flush() was causing GC cycles due to things being allocated/thrown away again. After some hunting in the source I found the following line:

https://github.com/GoodBoyDigital/pixi.js/blob/07e4e26f8fd404524a7ebaa73c210de3d8f2cf25/src/core/sprites/webgl/SpriteRenderer.js#L342

Here you see that we do a subarray on the vertex float data, send the result to the GPU, then throw it away again.

I removed this line to make it send all of the data every time. It seems like rendering still works fine, I think it just means we're sending a bit more data to the GPU, but we prevent GC pauses that can interfere with smooth animation. (Especially on our slow set top boxes where a GC every 15 seconds causes a 150-200ms freeze D:)

I think it might be possible to make the sprite batch just dynamically resize the float array when needed instead of every frame (I had "downsizing" working but not "upsizing") -- maybe this is the optimum? Game devs learn pretty early on that you should try to avoid constantly making/removing game objects from a scene, so the resizing should not happen often. For us, the temp fix of just removing the subarray is working nicely.

Any thoughts on this?

[englercj]

Do you have an example app the reproduces this behavior?

[davedx]

The app we're working on is closed source. I'll try and put together something that reproduces the behaviour.

[davedx]

Here's a demo repo: https://github.com/davedx/pixi_gc_demo

The code I patched is: https://github.com/davedx/pixi_gc_demo/blob/master/pixi.js#L17496

There's a screenshot of a sawtooth memory timeline in that repo too: https://raw.githubusercontent.com/davedx/pixi_gc_demo/master/pixi3.png

The weird thing is, if I remove the subarray and run it on our device (a set top box), we see almost no GC cycles if the app is idle (rendering every frame, no animations). With the subarray we see GC cycles every 15 seconds, enough to interfere with our app's UX. But in Chrome on Win 8, I actually still see the memory sawtooth whether I have the subarray or not.

Any insights into this? I'm not an expert on this kind of debugging. :)

[englercj]

Looking to implement a method like this:

#1939 (comment)

I think this will work well to help solve this issue as well.

[bchevalier]

I was wondering if that behaviour was consistant across all the browsers or if this was only happening on chrome?

[bchevalier]

Hello pixipeople, looks like chrome has improved their garbage collector:
http://v8project.blogspot.ru/2015/08/v8-release-46.html

See section "Reduce the Jank", there seems to be a lot of improvements regarding garbage collection and typed arrays, there is also a video to demonstrate the improvements. Seem a good news for pixi in general and I'm pretty sure it fixes this issue (at least when chrome 46 is released).

[davedx]

Not sure what the plan is for this? We still prefer a fixed batch size and not calling .subarray, but I think that would probably make Pixi too inflexible for other use cases...

[englercj]

There have been a couple of improvements to the particle container in recent dev code that allow you to specify the sizing of your container which should remove the need for the dynamic-ness.

(See: #1990)

Can you try rebuilding from the dev branch, and see if those features added from #1990 solve your case?

[GoodBoyDigital]

@davedx this has been addressed in the v4.0.0 branch of pixi. no more subarray 👍

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.