Why BitmapData.dispose comment out these codes? 🤔

Grimm · May 11, 2019, 11:11am

Grimm · May 12, 2019, 10:13am

Is it OK to simplify it like this?

if(__texture != null)
{
    __texture.dispose();
    __texture = null;
}

loudo · May 12, 2019, 3:15pm

Hello,

I think most people coming across your post will not try to understand where the code comes from. So you should link the lines of the code like this instead of using an image:

github.com

openfl/openfl/blob/769547ecbe5752f455a647294b04b4b254d0e0c9/src/openfl/display/BitmapData.hx#L745-L763


		// if (__texture != null) {
		//
		// var renderer = @:privateAccess Lib.current.stage.__renderer;
		//
		// if(renderer != null) {
		//
		// var renderer = @:privateAccess renderer.renderer;
		// var gl = renderer.__gl;
		//
		// if (gl != null) {
		//
		// gl.deleteTexture (__texture);
		// __texture = null;
		//
		// }
		//
		// }
		//
		// }

When you dispose the BitmapData, it cleans the RAM memory used for the BitmapData (all buffers set to null), but your linked Texture can still be used:) I think it’s still working that way. I don’t know why it is till in comment, maybe it’s till in beta.

singmajesty · May 13, 2019, 5:00pm

I think it is for a couple reasons:

On multi-threaded platforms, bitmapData.dispose can occur outside of the OpenGL thread, causing trouble
(Perhaps) the idea was to allow garbage collection to run for disposing the textures (which should be supported) rather than relying on an explicit dispose

If calling dispose immediately is giving better results, please let me know and perhaps we could make it platform conditional if it is a matter of threading

rainy · May 14, 2019, 2:40am

I added __texture.dispose to __texture. According to my tests, I can now run normally in C++ target and HTML5 platform. As far as I know, some garbage collectors do not necessarily release the texture actively.