Bug? with bitmap filter cache creation

hi there

running on openfl 9.1.0

I ran into a weird performance issue that I ended up getting to the bottom of. I was seeing an excessive amount of array allocations, resulting from new BitmapData from DisplayObjectRenderer.__updateCacheBitmap.
I placed some traces on all these instantiations in this function, the culprit seemed to be the one in this block:

if (displayObject.__cacheBitmapData2 == null
	|| bitmapWidth > displayObject.__cacheBitmapData2.width
	|| bitmapHeight > displayObject.__cacheBitmapData2.height)
	displayObject.__cacheBitmapData2 = new BitmapData(bitmapWidth, bitmapHeight, true, 0); // <-- this line
	displayObject.__cacheBitmapData2.fillRect(displayObject.__cacheBitmapData2.rect, 0);
	if (displayObject.__cacheBitmapData2.image != null)
		displayObject.__cacheBitmapData2.__textureVersion = displayObject.__cacheBitmapData2.image.version + 1;

Which seems to run only when a bitmap has filters.

Not only was this BitmapData instantiation being called consistently (about once every 10 or 20 frames?), but it was only called when the bitmap did not change from its previous state (for example, when I move a sprite around on the layer nothing weird happens, when I stop moving it will then start running this line repeatedly)
This behavior leads me to believe it’s a bug; that and it was causing noticeable stuttering and triggering the GC every second.
I tested with a ShaderFilter and a ColorMatrixFilter, both had the same result.

I have alternative solutions for what I was trying to achieve with the filter (just a simple shadow layer by darkening the children) so I’m not necessarily looking for a fix, but I figured it was a niche/substantial enough issue that I should mention it!



Hey @torcado!
Can you check if you get the same problem with openfl 9.0.2?
I guess, you better report it at Github, at least there is still some life over there: https://github.com/openfl/openfl