HaxeFlixel
Concerns about ``renderBlit``
I've recently been running some tests on the Flash target with Flixel, and I've noticed that it's not very well supported. Many common elements of Flixel are broken on renderBlit, such as FlxSprite alpha, coloring, blend modes, etc. This raises the question: is it really worth supporting? The lack of concern over so many obvious issues with renderBlit shows that it's an underutilized and deprecated target.
Another concern is how it's implemented. The renderBlit variable is set when FlxG is loaded and cannot be changed at runtime. This makes checking it as a variable at runtime (especially in cases like FlxSprite rendering) pointless, given that overuse of if statements can be expensive.
My solution? Either completely remove renderBlit and the Flash target to improve code quality and eliminate the headaches of supporting Flash, which continue to hold Flixel back from reaching its full potential. Alternatively, replace instances of if (FlxG.renderBlit) with a compiler flag like FLX_RENDERBLIT to reduce compiling times and improve rendering performance altogether.
render blit is not only used by flash, you can use it on any target when hardware=false in the project.xml, and some device's browsers will opt against webgl and use render blit. I see no reason to remove it, just because it seems less good than the alternative and you personally, don't plan to use it
The phrase "overuse of if statements can be expensive" is a weird, dogmatic and useless statement. Give me some actual metric of performance that this bool check will cause in a practical situation. For example: here's 10,000,000 ifs taking less than a 10th of a second. Also while it can't be changed at runtime, it also cannot be determined at compile-time, for reasons mentioned above (and maybe more).
If you see features that you think should be available on blit targets, make an issue about them. If you know of ways to avoid the blit target, make an (openfl) issue about them, if there is some actual evidence that the existence of flash and blitting is hindering your project, let me know. I'm not interested in theoretical optimizations about things can "can be" a problem in hypothetical situations
If there are cases where renderTile or blit CAN be determined at compile-time (perhaps enforced, is a better word, where an error message to imcompatible devices is given) I think we would implement this by making FlxG.renderBlit/tile an inline bool when the relevant compile flag is defined, and let the compiler optimize away the unused code and ifs, for example: https://try.haxe.org/#A598CCea
render blit is not only used by flash, you can use it on any target when hardware=false in the project.xml
Something worth mentioning, OpenFL's Graphics (which renderTiles uses) internally has multiple different implementations.
Context3DGraphics(Hardware accelerated),CanvasGraphics(Software renderer on web),CairoGraphics(Software renderer on native)- and even
FlashGraphics(which appears to implement stuff likedrawQuads()on Flash?).
Is it really necessary for Flixel to handle software rendering manually when OpenFL appears to do it behind the scenes?
By forcing FlxG.renderMethod = DRAW_TILES; and setting hardware=false in Project.xml we can see that rendering appears to work to a varying degree, depending on the target.
HTML5:
Hashlink (interestingly HL seems to suffer from #3278, which makes me more confident it's an issue on OpenFL's end):
Flash:
There are definitely issues but I'm not sure who's fault it is in the stack. I don't know if this would be a viable replacement to get software rendering working without the mess of having seperate rendering logic for blitting and quads but I'm just putting it out there as some kind of food for thought
Played around with this a little bit more and got Flash running by swapping out shader fills with bitmap fills (OpenFL and Flash shaders aren't intercompatible)
I wanted to do a perf comparison between this and renderBlit but for some reason I can't get FlxBunnyMark to work on Flash with renderBlit. It's just a black screen. Not sure if this is an issue on my end or if it's just broken.
render blit is not only used by flash, you can use it on any target when hardware=false in the project.xml
as much as I love bringing options for the programmer to tinker and satiate their interest... has really anyone used hardware="false"? even Godot 4 does not support any kind of software rendering
device's browsers will opt against webgl and use render blit
can it even do that though? I've never heard of that because what OpenFL/Lime does is to set up the game in a specific software/hardware rendering pipeline (that is why it is a project flag after all and thus a compile define thing)
The phrase "overuse of if statements can be expensive" is a weird, dogmatic and useless statement
Performance Cost of Using If Statements If-Else is Really Expensive Performance More Shaderprograms VS. IF Statements in Shader? The statement itself is not dumb, in fact if you overdo if statements, like many other things, can make it expensive and let's not mention that we're doing these conditionals on every frame of the game, it's kinda inducing to being paranoid lol but there's a reason why on GPUs, it's recommended to avoid if statements or Why are if statements in shaders heavily discouraged?
For example: here's 10,000,000 ifs taking less than a 10th of a second
I don't think this is valid because
- see Loop unrolling
- it downplays the issue, yes, it's a tenth of a second, (a millisecond for me), but to put it in perspective that is 100ms making a pointless conditional all the time, and that is for a short amount. 100ms in your machine does not mean it'll be 100ms on my machine or on a 2015 machine, and the draw function is looping until the game closes which can result in a hefty performance issue altogether. see Performance of OpenFL vs Flixel+OpenFL
has really anyone used
hardware="false"?
I don't think so, the only time I see it used, is here, but that seems purely academic
device's browsers will opt against webgl and use render blit
can it even do that though? I've never heard of that
Yes, we had to add this to advent because of reported issues
The phrase "overuse of if statements can be expensive" is a weird, dogmatic and useless statement
there's a reason why on GPUs
GPU ifs are Irrelevant to this discussion
For example: here's 10,000,000 ifs taking less than a 10th of a second
...Loop unrolling... ...100ms making a pointless conditional all the time...
These pertains only to my literal example, and not to the problem at hand
I don't think this is valid
Until someone has any evidence that the number of renderBlit/Tile checks are causing a noticeable difference in performance on any machine, I don't plan to make any changes to this system. Discussing whether millions of ifs are slower is not a useful discussion, and that's why I find these arguments dogmatic and a waste of my time
I'm down to continue to see when these values can be determined at compile time and have the optimizer remove these ifs in these cases at compile time, but I'm not interested in a theoretical optimization for something that isn't causing any known problems to anyone