Changing the scaling of displayobjects especially if they are containing bitmaps creates major performance issues in OpenFL 4.0 … The bigger the image gets, the harder the performance hit. I’m talking about drops from 60 to 0.5 FPS …This happens when setting the scale by code and swf assets using timeline animation. I’ve tested and found the same issues on Windows CPP and Android targets.
Whats going on, is this related to the new OpenGL renderer ?
This is related to upscaling graphics – we didn’t redraw when doing a scale in the older OpenFL releases, but users who were trying to get sharp full-quality graphics really wanted this. I’m not sure of the best compromise of hitting those quality expectations, while also keeping things snappy for animations that don’t rely on full quality vector.
Did it work alright for you in OpenFL 3.6.1 without legacy?
Yes… this works perfectly in 3.6.1. Now in 4.0 it breaks everything. The performance hit is so hard it makes 4.0 totally unusable with motion/animation that involves scaling. And that’s used quite a lot.
So it’s a major dealbreaker, just scaling a simple object results in serious fps drops. I understand the reason for upsampling, but this is not useable at the moment in my opinion. How about making this a manual operation instead of having automatic upsampling?
For now I have to downgrade to 3.6.1 and wait for a fix on this.
I believe this is where the upscaling happens:
https://github.com/openfl/openfl/blob/develop/openfl/display/Graphics.hx#L728-L737
If you force the width and height to not change, it should not force a re-render. Could you try and comment this and see if it behaves differently for you?
Yep. If i comment out setting the new width and height, performance (tested on Android)
goes up from 0.5 fps to 60 fps:
// __dirty = true;
//__renderTransform.a = width / __bounds.width;
//__renderTransform.d = height / __bounds.height;
Has the new upsampling been tested enough? I’ve tested on android and windows so far, and it simply isn’t usable, atleast as far as all my tests go. Setting scaleX =3, scaleY =3 on Android results in a ->2<- second freeze, on a fast phone… And thats for a simple 800x600 image. Hope you will consider doing some workarounds here.
Apart from that i have to say because OpenFL 4.0 is great, i really love it! 
We could consider doing a straight-up #if disable_graphics_upscaling define to disable this code, or, we could set limits on the final target size, or how many times we will scale, or try to add some other logic in order to more intelligently determine how often to change the scale. We could possibly try and figure out how much the object is changing frame over frame, and limit the redraws based upon that
Performance is important here, so an option to turn it off is needed i think. But removing those lines created a lot of bugs, texts and graphics dont get their correct sizes and clipping occurs several places. So i guess the correct size needs to be calculated first.
But limiting size or measuring the size changes, would still trigger the upsampling at some point? …
I’ve added openfl-disable-graphics-upscaling as a define for right now, to disable the scaling logic. I believe the other components of OpenFL (such as hit testing, etc) should still work with this patch, but we can try it out more and see how it behaves, and make additional fixes if needed.
I’d like to see this go away in the future, and find some way of automatically determining how to handle this behavior, but for now, I think it’s good to be able to instrument it manually
Thanks