Safari Cleanup Issue

[aalex]

I’m building a SPA (vue js + vue router) combined with some pixi js (v4.8).

The main features I use are :
- image sprites
- video sprites
- some pixi texts
- displacement filters

Depending on the view, there may or may not be a canvas/renderer. But I always cleanup after myself before switching views by : 
- destroying every sprite and their baseTexture (image, video, filter sprite) -> .destroy(true)
- destroying every text and their baseTexture -> .destroy(true)
- clearing any filters used -> container.filters = null
- and finally destroying the main renderer -> renderer.destroy(true)
By doing so, my SPA is running smoothly (chrome, firefox, edge), no matter how many view switches occurs, and I don't get any console errors.

However, safari (12.0.3 in my case) simply doesn't seem to take any cleanup seriously, after 4/5 views switching the performance drastically drops and I get many console errors : _There are too many active WebGL contexts on this page, the oldest context will be lost._ and _WebGL: INVALID_OPERATION: loseContext: context already lost_ . And if we continue browsing between views, safari will be forced to crash. Even if I manually try to kill my renderers with _gl.getExtension('WEBGL_lose_context').loseContext()_ , the problem remains.

Am I missing something or is it just the way Garbage Collection works in safari (being less effective, and not properly releasing memory)?

[ivan.popelyshev]

Its strange. Btw, pixijs does have one more , testContext, that it uses in some cases for shaders. It shouldn't be critical if your app was started and test context was lost.

Thank you for posting the issue, maybe we can reproduce it with pure webgl and report it somewhere.

[mattstyles]

Interestingly, there is a proposed workaround noted in the description of this issue (on a totally different project), https://github.com/openlayers/openlayers/issues/9291

Quote

Safari on iOS 12 has a bug where it doesn't properly garbage collect canvas elements unless you explicitly give the canvas elements a width and height of 0 when they are no longer meant to be used. See https://bugs.webkit.org/show_bug.cgi?id=195325 and the reduced testcase I attached to that bug report.

Also linked is a bug report to webkit.

[bigtimebuddy]

In this case, for SPAs it’s better to not destroy your renderer. You can destroy the display objects (sprites, textures, etc), but keep the reference to your canvas and renderer (make sure you pause the ticker). There’s a limit to how many webgl canvases you can create simultaneously. Better to not continually create and destroy. Maybe there’s some GC trick for Safari, but this has been my standard practice working with virtual dom frameworks.

[aalex]

Thank you all for the quick replies and different leads, much appreciated.

Unfortunately setting the width & height of the renderer to 0 or 1 before destroying it, does not resolve the issue.

I believe @bigtimebuddy's workaround is one of my last option (to keep a 'global' renderer and recreate scenes in it), but will demand a huge app restructuring. Even more since some of my SPA views fades in/out with multiple renderers visible at the time of transition.

Is there a way to keep/store a canvas reference and re-set it to a new canvas/renderer?

Thanks again!

[bigtimebuddy]

The canvas and renderer are bound so you can’t just reassign canvas. You can use two renderers, however, if you want to cross fade or alternatively export the canvas to an image that you fade as a dom element on top. 

Sorry, no easy option here.

[aalex]

Sorry for the late reply.

I ended up with 3 global canvas/renderers (which is the highest number possibly visible at a same time).
I then, move them around, and clean/re-create my different scenes as need be. Works pretty fine, the performances are good, and the experience stays smooth.

Thanks again all !

 

 

 

[ivan.popelyshev]

And the Poscar for the optimizations goes to...