Locking only part of an image

BlitzMax Forums/BlitzMax Programming/Locking only part of an image

Robert(Posted 2005) [#1]
Currently the LockImage command locks the whole image, which means that when you UnlockImage, it is slow to update for large images (slow enough to be prohibitive for real-time work)

In some situations large images can be split up into smaller ones, in others however this makes the rest of the code much more complicated.

Would it be possible to extend the LockImage command so that, optionally, only part of the image would be locked, thus speeding up the UnlockImage call?


Dreamora(Posted 2005) [#2]
To really speed up use pixmaps as locking converts to pixmap and back again.

images are not really meant for "realtime operations" on them.

and locking only a part of it is not possible.


ImaginaryHuman(Posted 2005) [#3]
Um.. Instead of using LockImage on the image, which then transfers the image into main memory, performs changes on it there, and then transfers it back ... maybe keep 1 copy of the currently-to-be-seen image in videoram as an Image, and another copy as a pixmap in main memory - when you need to make a change, just update the pixamp and then turn it into an image, which saves on unneeded transfer time.

Which is what dreamora was saying.


Robert(Posted 2005) [#4]
Looking at the Max2D source code, that is effectively what happens anyway. LockImage simple returns the internal TPixmap object (ie. it does not create a new pixmap), and UnlockImage uses bindTex and uploadText to copy the changes to the image itself.


Mark Tiffany(Posted 2005) [#5]
Certainly with previous versions of Blitz using DirectX, and I *suspect* now with OpenGL too, the slowness of locking an image has relatively little to do with the size of the image. Okay, so there's the obvious memcopy, but in DirectX, lockimage could vary in speed depending on when in the frame you did it.

I could of course be completely wrong, just saying that I'm not convinced reducing the size of the image will necessarily result in faster locking...


Hotcakes(Posted 2005) [#6]
I would imagine the greatest bottleneck would be sending the new image down the AGP bus.