When I use BitmapData.setPixels(), the ByteArray has to be exactly the size of the passed rectangle (or larger, I assume) for it to work. If it’s smaller, it crashes with an EOF error.
I understand why this happens, but what I want to do is that once it reaches the end of the ByteArray, it simply fills the remaining pixels with 0 (transparency on transparent BitmapDatas, or black on non-transparent ones). I could of course do this by writing the pixels manually using setPixel32() but that would be a bit bothersome and probably much slower.
Would it be possible to implement this somehow? Maybe even adding an extra optional parameter for the remaining pixel fill colour? Otherwise does someone know a workaround that won’t significantly impact the speed?
OpenFL is designed to match the Flash API’s behavior, so they aren’t going to add another parameter.
Fortunately, you can work around it with only a few more function calls.
First, find the row in the bitmap where the EOF error will occur. (I’ll call this the “problem row.”)
Fill everything above the problem row with one setPixels() call. Fill everything below the problem row with fillRect(), and fill the problem row by hand.
Alternately, you can set up some more rectangles, and fill the problem row with one setPixels() call and one fillRect() call. (Conveniently, setPixels() will continue reading the ByteArray where it left off.)
Ah thank you, I hadn’t thought of using multiple rectangles. Works great! I don’t even need to call fillRect() since I simply want transparency, which I fill the BitmapData with initially.
I thought that OpenFL would also allow itself to make some improvements to the API, at least in the openfl package. If that’s not the case though then I guess that’s that.
Now that you mentioned it, openfl.Vector does add a few things that flash.Vector doesn’t have. However, it took a fair amount of extra code, and BitmapData.hx is already pretty long.
For now, how about making a static extension method? Put it on GitHub and see how many people use it.
I think that we’ll see optimizations to BitmapData manipulation in the future using TypedArrays, so you can get the pixels, then we’ll try and speed up swizzling and other operations. If you have something specific that you think doesn’t have a good enough path to do in an optimized way, let me know. Generally, you just make sure that you create a ByteArray that’s at least (width * height * 4) in bytes
Well basically, what I’m attempting to do is allow the user to change the width of the image, seeing which is the best looking one (they load raw pixel data without any size information). They need to be able to do this fairly smoothly, essentially “scrolling” through widths until the image forms what they’re looking for. I do this simply by making a new BitmapData with the new width (and a corresponding height) and then calling setPixels on it with the same pixel data.
Naturally, this means that the ByteArray will not always fill the bottom line, unless the ByteArray is exactly the right size, hence my question. One alternative is modifying ByteArray itself and filling it with the necessary bytes at the end, but I don’t know how to go about appending bytes to a ByteArray (although if it’s possible then it might be quicker than the current method).
In any case, for now I’ve gone with player_03’s suggestion of making a static extension which works well, I didn’t even know such a feature existed! I’ll put it up on GitHub later today, unless we find a better solution before then.
