Correct way to work with RGB/ARGB bitmaps?

@All

I want to write code that will load a bitmap when needed, display it, and then switch to another bitmap as required, and so on.

This should be done in a ReAction window using the bitmap.image class.

Currently, my approach is to create two bitmaps: a user bitmap and a VRAM bitmap. The user bitmap (in RAM) is used for all modifications, and then I blit it to the VRAM bitmap for display.

To achieve this, I created a render() function that takes the number of the bitmap to render.

The entire function looks like this:



Then in the main i do:



So, the first call to render() works perfectly. Everything displays correctly, with no issues. However, on the second call, I often encounter a lockup, either during SetAttrs on the bitmap.image or on RefreshWindowFrame().

When I add more Printf() calls in between, it seems to introduce a delay that allows something to complete, and the lockup sometimes disappears. But when I add more code, the lockups return.

I’m sure I’m missing something critical, like waiting for BltBitMapTags to finish or something similar. It feels like a classic race/timing condition, but I seem to lock/unlock bitmaps when needed, so what’s going wrong? I’m using two bitmaps specifically to avoid unpredictable behavior—doing all the work in the RAM-based bitmap and then blitting to the VRAM bitmap afterward—and yet, it still feels like I’m doing something wrong.

Also, another question: What is the fastest way to display bitmaps on AmigaOS 4 currently? Is BltBitMapTags the best option? Is it accelerated by compositing? If not, should I use compositing instead?

And which approach is better:

Load all data into one large bitmap and navigate through it (but this could be problematic since bitmaps are limited in size, probably 2048x2048 or something like that), or
Load all the data into memory, then create bitmaps each time and blit them as needed? However, constantly creating and freeing bitmaps for every change seems excessive to me.

Thanks for your answers in advance!

You called the first render() before you created the bitmapobjet if that code is right.

But other wise next render you delete the bitmap whilst attached to the bitmapobject, that wont go down well.

@kas1e
Quote:The internal BltBitMapTags() implementation should be based on CompositeTags(), at least on supported gfx cards (ATIRadeon.chip, RadeonHD.chip and RadeonRX.chip).
Using CompositeTags() yourself gives your more control, but shouldn't make much difference for the speed.

@broadblues
Quote:

Yeah, were in hope for some reverted logic, but in end turns out it better to go flat one, one after another..

@joerg
Do you know if there restrictions on bitmap size starting from which it's no more hardware accelerated ? I just noticed, that when i have bitmaps bigger that 2048x2048 (or something around that, but no more that 3000x3000 for sure), things start be slower and slower

@kas1e

Hi, this is how I do it on mgbaGUI and denGUI:


just change/remove code to use "BITMAP_BitMap" instead of "BITMAP_SelectSourceFile"

@Javier
That just you set ready image, that not problem, and setting bitmap no problem. Just working with bitmaps itself are as i know nothing about their limitations and how they should be handled.

So far i got that you should lock bitmap only for getting pointer to the buffer. Also that you should use BltBitMapTags() which should be compositing accelerated, but i still dunno to what extent: i found that if bitmap are more thatn 2048x2048 all start to be much slower, like, they start to be software rendered instead.

Also, how is better to works with bitmaps to have best as possible speed ? I mean, if i have 10 1920x1080 images, between which i want to flip, should i load up all of them to the RAM at once, or load up them one by one. Just want to understand how to do it all for better speed.

@kas1e

Ok, maybe this thread helps:
https://os4coding.net/forum/p96lockbitmap-freezes-system