newBitmap(73, 55) returned LCDBitmap with rowbytes of 12, not 10

SDK Get Help
,
1

I'm using SDK 2.0.1, and everything below was tested only in the Simulator, running in Windows 11 with Visual Studio 2022.

I created a 73x55 1bpp png, loaded it via graphics->loadBitmap(), and then called getBitmapData() on it, it said the rowbytes was 10, which makes sense (73 / 8 = 9.125, so you'd need at least 10 bytes per line).

Then I called newBitmap(73, 55, kColorWhite), but when I retrieved its rowbytes, it was 12. This messed up some other code I had written that naively tried to memcpy the image data from the loaded image to the new bitmap.

I ended up switching from newBitmap to copyBitmap, which created an LCDBitmap with the same rowbytes of 10 as the original.

So I'm just curious why newBitmap does that. Is it padding out on purpose (maybe to hit DWORD alignment? but then why doesn't it matter that my loaded bitmap isn't DWORD aligned?)

3

I noticed that.. 4 months ago, according to gitlab. I'll just paste what I filed there:

pd->graphics->newBitmap() is rounding rowbytes up to 32-bit boundary

We started allowing 8-bit alignment a while back so that fonts are encoded more efficiently. Before we change it here too we should check for performance differences. I doubt it'll be anything noticeable but 32-bit aligned access is slightly faster; on the other hand, more padding increases cache misses.

So yeah, it was just an oversight, and left at low priority because we hadn't heard of anyone having any problems with it. I've attached your report to the issue and bumped priority up a notch, fyi. Thanks for the note!

2 Likes