aalex

Safari Cleanup Issue

Recommended Posts

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)?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.