Samuel Girardin Posted April 9, 2016 Share Posted April 9, 2016 Hi, I've just noticed some strange behaviors when disposing a spritemanager using dynamic texture : - when you remove a spritemanger, there is still a texture in the 'stack' -> http://www.babylonjs-playground.com/#1GWIGC#13 Maybe we can fix this by testing imgUrl in spriteManager.ts. It seems to solve the problem. if (imgUrl) { this._spriteTexture = new BABYLON.Texture(imgUrl, scene, true, false, samplingMode); this._spriteTexture.wrapU = BABYLON.Texture.CLAMP_ADDRESSMODE; this._spriteTexture.wrapV = BABYLON.Texture.CLAMP_ADDRESSMODE; } One other thing when using a bitmap texture, how correctly remove sprite and spriteMananger. You can see here a 'no texture bound to GL_TEXTURE_2D error' -> http://www.babylonjs-playground.com/#2IPMDX#7 [edit was a wrong playground] The first spriteManager.dispose() no throw error, the second does. Any idea ? Quote Link to comment Share on other sites More sharing options...
RaananW Posted April 9, 2016 Share Posted April 9, 2016 Hi sam, first about the second error - this is because the texture is shared between the two sprite managers (same url, texture is cached). We just had the discussion regarding cached textures and dispose, but in this case it is a bit more complicated, as the texture is created inside the sprite manager. You can prevent it this way - http://www.babylonjs-playground.com/#2IPMDX#8 (cloning the texture). Quote Link to comment Share on other sites More sharing options...
RaananW Posted April 9, 2016 Share Posted April 9, 2016 Regarding the first problem - when setting the texture for the sprite manager, the old one is not being disposed. disposing it before setting the new one will do the job: http://www.babylonjs-playground.com/#1GWIGC#16 Again about the discussion we had - to prevent disposing reused textures we decided to leave the texture disposing in the hands of the developer. so in this case you will have to know that the old texture should be disposed. The set texture method can dispose the old one, but this will be a problem if it is used somewhere else. Quote Link to comment Share on other sites More sharing options...
Samuel Girardin Posted April 11, 2016 Author Share Posted April 11, 2016 HI Ranaan, For the first problem, ok I understand. Thanks a lot For the second, one thing I don' t understand.If you have only one sprite and one sprite manager, and you dispose both. You still have the webgl error. Is there a way to prevent that ? http://www.babylonjs-playground.com/#2IPMDX#9 Quote Link to comment Share on other sites More sharing options...
RaananW Posted April 11, 2016 Share Posted April 11, 2016 Hmmm.... Async problems. The proble ist that you are disposing the texture before it was even created (javascript is crazy like that). here, this works - http://www.babylonjs-playground.com/#2IPMDX#10 One day, when promises will be in all browsers, this will be much easier to solve . I don't see a quick solution, but I haven't looked too deep into the code. If you have this kind of case, make sure first that the texture was created. This line is the problem - https://github.com/BabylonJS/Babylon.js/blob/master/src/Sprites/babylon.spriteManager.ts#L34 . The texture's constructor accepts an onload callback, but where will you define it?... Adding more params to the spritemanager's constructor will probably create unwanted chaos So, just wait a bit, or always dispose with a getTimeout, this would be my (tmp) solution. I will see if there is a nicer solution anyhow. Like adding a default onLoad function to the texture and checking if it was disposed in the meantime. Let me think about it Quote Link to comment Share on other sites More sharing options...
Samuel Girardin Posted April 11, 2016 Author Share Posted April 11, 2016 shame on me... ! thx !! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.