Am I using BitmapData.paletteMap() correctly?

[MegaLeon]

Hey everyone,
I’m playing around with a raycasting engine in haxeflixel and getting some performance issues.

I have a _canvas flxsprite which I use to draw the whole screen. At first I was using _canvas.pixels.setPixel but that was very slow. I moved to a cool technique of writing values to a bytearray and converting it to pixel data as outlined here http://board.flashkit.com/board/showthread.php?741099-AS3-Fast-full-screen-touch-every-pixel-updating. Way better - hit stable 60 fps.

Now I’m trying to use paletteMap() to remap it to an indexed color palette, after reading how fast this method was here: http://www.splashdust.net/2009/11/bitmapdata-and-palettemap/ and in several other places.I’m using

var rect:Rectangle = new Rectangle(0, 0, FlxG.width, FlxG.height); 
_canvas.pixels.paletteMap(_canvas.pixels, rect, new Point(0, 0), null, null, null, palette);

where palette is my array of int colors.

The visual result is correct, but the performance is terrible. 10 fps, even worse than using setPixel() - can’t be right. Am I accessing the bitmapdata of _canvas in the wrong way?

Cheers
L

​

[SruloArt]

* AFAIK paletteMap isn't always fast, it can be even slower than the alternatives.
* Your palette is an array of alphas?

[MegaLeon]

No, I write the color index in the alpha byte compenent of the int for convenience. Afterwards paletteMap uses that index to replace that pixel with the color in my palette array. 

It's working correctly, just a tad disappointed in the performance since commenting the paletteMap operation out everything stands at 60 fps (after all ray calculations, writing values in the bytearray buffer and copying them to the screen bitmapdata), then when I use it it falls down at 10 fps.

Especially after many people were chanting how fast it was compared to whole-screen setPixel()

That why I was wondering whether I was accessing the bitmapdata using the wrong method, maybe creating a copy of it each frame by mistake (I remember reading something about that behaviour in haxeflixel)

Alas I tried using _canvas.cachedgraphic.bitmap (or something like that) and the result seems the same.

[SruloArt]

* ok, I guess I need to read the thread you've linked to catch up. :)

* I've tested several projects where paletteMap is implemented (like Mandelbrot (http://www.splashdust.net/2009/11/bitmapdata-and-palettemap/), https://github.com/01010111/Redshift-Blueshift---/blob/4cbe4bfbcef2f6a0e83f643249dedf5244b4be98/source/util/ZState.hx, https://github.com/schonstal/Ludum-Dare-32/blob/eef799e88b406d9f3e0886aa3070db4b9d395cad/source/EffectSprite.hx, and https://github.com/jkwestin/woodtexture/blob/2822967b41839f71b978c349c39f1674632a579b/WoodTextures/source/WoodTexture.hx), everything seems pretty darn fast, so maybe you're indeed doing something wrong :)

* I'd say, use a tempBitmapData as a copy of your _canvas.pixels, and when you're done with paletteMapping it, just _canvas.pixels = tempBitmapData. It would not use the actual sprite.pixels since setting pixels is always using a copy bd, but this shouldn't matter since it's the only copy.

On Thursday, September 24, 2015 at 12:00:45 PM UTC+3, MegaLeon wrote:

No, I write the color index in the alpha byte compenent of the int for convenience. Afterwards paletteMap uses that index to replace that pixel with the color in my palette array. 

It's working correctly, just a tad disappointed in the performance since commenting the paletteMap operation out everything stands at 60 fps (after both ray calculations and writing values in the bytearray buffer), then when I use it it falls down at 10 fps.

[MegaLeon]

Update: this effectively runs at 60 fps in the flash target with a normal _canvas.pixels.paletteMap (hell, even setPixel() seems to go on decently). Performance is abyssmal only on the neko / windows / android target. Which is a shame, I wanted some cross-platform sweetness.

Update2: My bad. It actually run full speed on windows target (alas at very low resolution, 320x180). Android looks decent, haven't had a look at fps yet. Only neko seems to struggle, at 10 fps. Wonder why.

Some other discussions about this:

- http://stackoverflow.com/questions/10157787/haxe-nme-fastest-method-for-per-pixel-bitmap-manipulation

- http://www.openfl.org/archive/community/general-discussion/pixel-level-manipulation-of-bitmapdata/

Also, flash compiling was broken for me with the latest haxelib upgrades. Had to roll back to lime 2.3.2, openfl 3.0.2 and swf 1.8.5 (I just rolled back to the earliest versions I had on this machine)