Abstract BitmapData to allow ram dumping

[Geokureli]

Rough Idea

Deprecate myFlxGraphic.bitmap, any other uses of Bitmap and add some graphic.startManipulation() method which returns an object with Bitmap's drawing tools, which somehow requires a finalizing end() call to dumb the Ram

[ACrazyTown]

Some food for thought, here's how a couple different frameworks/engines tackle this:

• Unity
  • There's a single Texture2D class, hardware-only by default, that handles both the software pixels and GPU texture. I guess in this way it's similar to OpenFL's BitmapData
  • Use Texture2D.ReadPixels() to download the pixels from the GPU, do whatever edits, and then Texture2D.Apply() to upload it back to the GPU (and optionally dump the software pixels)
• Godot
  • Has an Image class that can be edited. In order to be used for rendering, it needs to be turned into a ImageTexture
  • Can get the pixel data via Texture2D.get_image(), and update it via ImageTexture.update()
• Heaps
  • Similarly to Flash, has a BitmapData class for software pixels. In order to be used for rendering, it needs to be turned into a Texture first.
  • Also has methods to download and upload pixel data.

I think for Flixel 7 we could consider making FlxGraphic use hardware textures only by default, since most people don't need to edit graphics. Readable textures could be requested with an optional parameter to some method, or we could add a new method to download the pixel data back from the GPU.

[Geokureli]

I'm leaning towards:

final tex:FlxTexture = FlxG.assets.getTexture(assetPath);
final bitmap:FlxBitmap = tex.getBitmap();
// draw to itself with inverted colors using the forwarded (or similarly defined) BitmapData.draw
bitmap.draw(bitmap, null, invertColorTransform);
tex.apply(); // apply(dump = true)

// ALL of the following names suck
switch tex.status
{
     case LOCKED:
          trace("The Texture is only in VRAM"); // Should be in this state, because it was dumped in the apply() call
     case UNLOCKED(bitmap, true):
          trace("The** texture exists in both RAM and VRAM, and they are synced");
     case UNLOCKED(bitmap, false):
          // not possible in openfl?
          trace("The texture exists in both RAM and VRAM, which was edited, and not yet applied");
}

or maybe tex.bitmapStatus and instead of locked/unlocked we can use DUMPED, FLUSHED or HARDWARE?

I feel like with this way, we can keep existing things in tact for a while. FlxG.assets.getBitmapData can still return a bitmap which can be passed into sprites and junk, and there's a way for things n the backend to get the texture from the bitmap (or create one if the dev used new BitmapData()). FlxGraphic will use textures instead of bitmaps, but if the (now deprecated) graphic.bitmap getter is invoked it creates the instance and leaves it undumped and editable. We don't really need an "apply" method for openfl, it seems like they are auto applied, but other backends may need this; openfl really just needs a way to dump the ram when you're done

[ACrazyTown]

I'm a fan of that snippet, I think that might be the way to go.

Maybe instead of a status variable and an enum we can do something similarly to OpenFL and Unity and have a readable bool. If true, there is a present bitmap we can read/write to, otherwise it's a texture only.

We don't really need an "apply" method for openfl, it seems like they are auto applied

This is true, the texture is updated the next time bitmapData.getTexture() is called, which is usually when it gets rendered. We could just force the texture upload immediately though, for consistency.