Locking only part of an image
BlitzMax Forums/BlitzMax Programming/Locking only part of an image
| ||
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? |
| ||
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. |
| ||
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. |
| ||
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. |
| ||
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... |
| ||
I would imagine the greatest bottleneck would be sending the new image down the AGP bus. |