Wanderer wrote:
Of course I am teasing you here to get a discussion running, forgive me

But a fact is, that CGX has a function called LockBitmapTagList(), and it is described in the CGX documentation what it is supposed to do.
The return value should be checked of course, like any other function that can potentially fail. I changed that in my code.

But the question remains if this is a valid implementation, if it ALWAYS fails. You could write an OS where fopen() always fails. Surly, if your application is correctly written, it can gracefully terminate with an error message, but it wont get productive.

The CGX docu says it CAN fail, sure, but always?

The docu also says this is the only legal way to access the bitmap directly. Means in return, AROS does not provide the functionality to access a bitmap directly. And this means Extra code for software developers or the software wont run on AROS.

EDIT:
If I cannot access the bitmap directly, I need to do the follwong workaround:

- allocate pixelarray that can hold the bitmap data
- ReadPixelArray()
- manipulate the pixelarray
- WritePixelArray()
- free pixelarray

instead of

- manipulate bitmap

The memory overhead is the pixelarray (which can get quite large for large images) and the runtime overhead is two large memory swapps form/to the bitmap. Actually I do this if I manipulate foregin bitmaps, like from a Window. But I really would like to avoid this for private, well defined pixelformat bitmaps.

Imagine you want to do a panic save of your work in a Paint program, because you run low on memory. There is no way to make another huge allocation just for saving the bitmap. And AROS has no VMEM, I guess, to compensate this.