Software rendering broken on Hashlink

[ACrazyTown]

• Haxe version: 4.3.6
• Flixel version: 5.9.0
• OpenFL version: 9.4.0
• Lime version: 8.2.0
• Affected targets: Hashlink

To reproduce set hardware="false" on the window tag in Project.xml

---

Code snippet reproducing the issue:

Empty state

---

Observed behavior:

Graphics seem to get rendered on top of each other and are never cleared.

Expected behavior:

Consistent rendering like how it is on other targets

[Geokureli]

I was able to reproduce this issue in a pure OpenFL project and created an issue, there

[ACrazyTown]

Hmm.. I can't reproduce it in a project made thru openfl create project but if I put the same code from your issue in Main.hx of a flixel project it seems to happen. Not sure if I'm missing something

EDIT: Doing FlxG.camera._scrollRect.removeChild(FlxG.camera._flashBitmap); seems to fix it. Not sure why this would be affecting graphics globally?

[Geokureli]

Doing FlxG.camera._scrollRect.removeChild(FlxG.camera._flashBitmap); seems to fix it. Not sure why this would be affecting graphics globally?

After looking into this, I notice that hardware="false" causes flixel to use "blit" rendering. Which I have to assume comes with a hefty performance hit. What benefit drew you to try hardware="false"?

[ACrazyTown]

After looking into this, I notice that hardware="false" causes flixel to use "blit" rendering. Which I have to assume comes with a hefty performance hit. What benefit drew you to try hardware="false"?

I tried it while working on the maxTextureSize changes

[ACrazyTown]

Resizing the window once fixes the issue and makes it work as intended. I'm really confused as to where the cause of the issue is

[Geokureli]

Given that hl on hardware=false is a very niche use case I'm gonna take this off off 5.9, let me know if you come up with a good answer. My guess is that we are not checking FlxG.renderBlit somewhere on hl since it's rarely tested

[ACrazyTown]

My guess is that we are not checking FlxG.renderBlit somewhere on hl since it's rarely tested

Why would it be affecting things such as the mouse sprite and debugger or any other non-flixel level things? And the fact that resizing the window seems to fix it makes me feel like the issue is outside of the flixel level

[Geokureli]

In an attempt to narrow this issue down I extended FlxGame and started removing all functionality that doesn't seem to cause this. this is where I'm at so far:

package tests;

import openfl.display.Bitmap;
import openfl.display.BitmapData;
import openfl.display.Sprite;

class BlitHLTest extends Sprite
{
    public function new ()
    {
        super();
        
        // make a box follow the mouse for testing
        addChild(new MouseShape());
        
        final stage = openfl.Lib.current.stage;
        
        // recreates issue
        final sprite = new Sprite();
        sprite.scrollRect = new openfl.geom.Rectangle();
        sprite.addChild(new Bitmap(new BitmapData(stage.stageWidth, stage.stageHeight, true, 0)));
        addChild(sprite);
        
        // No issues when scrollRect is on the bitmap
        // final sprite = new Sprite();
        // final bitmap = new Bitmap(new BitmapData(stage.stageWidth, stage.stageHeight, true, 0));
        // bitmap.scrollRect = new Rectangle();
        // sprite.addChild(bitmap);
        // addChild(sprite);
    }
}

class MouseShape extends openfl.display.Shape
{
    public function new ()
    {
        super();
        
        final stage = openfl.Lib.current.stage;
        
        // recreates issue
        stage.addEventListener(openfl.events.Event.ENTER_FRAME, function (event)
        {
            graphics.clear();
            graphics.beginFill(0xffffff, 1);
            graphics.drawRect(stage.mouseX, stage.mouseY, 100, 100);
            graphics.endFill();
        });
        
        // No issue
        // graphics.clear();
        // graphics.beginFill(0xffffff, 1);
        // graphics.drawRect(stage.mouseX, stage.mouseY, 100, 100);
        // graphics.endFill();
        // stage.addEventListener(openfl.events.Event.ENTER_FRAME, function (event)
        // {
        //     x = stage.mouseX;
        //     y = stage.mouseY;
        // });
    }
}

Update: I think I've narrowed the issue down to OpenFL

[Geokureli]

The buck has been passed

Moving this off of 6.1.0