-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tearing down a webgl Pixi renderer and clearing cache #460
Comments
Pixi uses a lot of globals (like BaseTextureCache and TextureCache) which is the main issue. If you clear those the browser should eventually get around to deleting the old WebGL context. It would be cleaner if Pixi explicitly deletes resources, though. We'd need to add the following features;
IMHO it would be good to consider context loss since it's related to the whole aspect of context creation/teardown #357, and it will become more pertinent when WebGL support improves on mobile devices. Generally speaking you should do your best just to have one WebGL context, and re-use it, instead of constantly creating/destroying WebGL contexts. |
Thanks for the reply! Looks like pull request #347 does most of the cache clearing and would be a good starting point. Only difference seems to be I'm not trying to restore the original context. Is that accurate? |
Yeah. #357 is more about context loss events (which can happen at any time with WebGL, mainly on mobile), and recovering from them without forcing your user to re-load the page. In your case, things should work if you just clear the texture/shader/whatever globals. |
@GoodBoyDigital @mattdesl Lots of great work happening that I have been perusing on vacation 🎆 Still a little confused about the context handling overall. I see the introduction of context IDs, and breaking things out into managers, but there still seems to be a global context hanging around and referenced in a couple places. Just wondering if there is still some more cleanup to be done? Maybe just in src/pixi/renderers/webgl/WebGLRenderer.js? |
Just peering at the additions now. I'd be careful with adding properties to an object after creation, since it's not optimal for V8. I'm sure it's not such a huge deal though.. Overall the changes look good, and will probably make contributions much easier in the future! 👍 |
@mattdesl I've seen that too. I guess since the ids are integers, would an array be more optimal in this case? |
Interesting stuff! @drkibitz Yes there could very well be some clean up to be done. There is one global reference for the default renderer to help simplify using render textures. Mainly because creating and using a render texture requires that it knows which context it belongs to. Figured as most people will still only use one renderer on screen that the global default renderer can be used if none is passed to it. Happy to take suggestions on how to make that a little better. Maybe a render texture should have the renderer passed to it through its constructor? Other than that there should be know more global variables in PIXI other than some constants and the texture cache. @mattdesl Good call! I will definitely be going through and checking that its optimal for v8. I think the majority of the codebase should be fine - but I'm sure theres probably a view variables that will need to be set in the constructor that may not be right now. Let me know if you bump into any! Thanks guys! |
@GoodBoyDigital thanks for trying, but still confused. Looks to me that RenderTexture already has a reference to the renderer https://github.com/GoodBoyDigital/pixi.js/blob/master/src/pixi/textures/RenderTexture.js#L52 Unless you made this change after that comment ;) |
@drkibitz oh! you are indeed correct, must have changed it without remembering - its been a busy pixi week :) |
You have a good eye! You have every right to be confused by them too - they are either legacy or need tweaking. Will make sure to sort those out next. Thanks for pointing them out! |
What's the difference between
So glContextId is set on instantiation, and id is set there, and on context restored? |
Can this issue be closed, or is it still open? |
I vote close. It's not a bug more a a feature request. The workaround for On Sunday, February 9, 2014, Chad Engler notifications@github.com wrote:
|
Cool - nows probably a good time to mention there is actually some tear down code in the webGL render now so it can now be destroyed :) |
Thanks will check out the latest! On Sunday, February 9, 2014, Mat Groves notifications@github.com wrote:
|
rad! let me know if it all works ok for you! |
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. |
Is there a way of tearing down a Pixi renderer so that it cleans up after itself (clearing any shared resources) so that a new instance can be created without any references to the old webgl context? I get an error about references to a different webgl context when removing a renderer canvas and creating a new one.
Shared context appears to be the problem (as per issues #298 #181 #23) that people experience when trying to use multiple webgl renderers at the same time, but it also happens if you remove the canvas and re-create it without a page reload.
The text was updated successfully, but these errors were encountered: