You definitely don't want to try converting the entire pixmap into an image.
When you lock the image you are saying to the system that you want the handle to the image to be kept and not lost and that you want to change the image. If you change it, it HAS to be re-uploaded in full to the graphics card via the graphics bus. It will not detect the changes in the image to optimize the upload, it just sends the whole thing. The transfer from the pixmap in main memory to the image in video ram is what is causing the delay - and you should avoid having to make that transfer as much as possible. A pixmap is in main memory and cannot be displayed by the graphics driver, which is why you have to upload it whenever you've made some changes. However, like you said, if you compose your game world from various smaller images, each with its own smaller pixmap, then you only have to upload (when you unlock the image) the pixmaps that contain changes (ie mark them as dirty etc). You should also be only uploading enough images that are required to display a full screen of the game world - you do not need to hold the entire 4000x4000 texture data in video ram at all times, only the parts that are needing to be displayed, and you should then have the changing areas or the areas which are coming into view be reuploaded via unlocking those image. You have to use a pool of generic dummy images so you'll need to indirectly reference them.
To change the pixmap, use either readpixel/writepixel or use pointers in combination with PixmapPtr()
It is a good idea to make the higher-level multi-image type that you suggested. Then when you need to write to a given pixel it will abstractify the coordinates and write it into the appropriate pixmap.
It is also good to bear in mind that the maximum texture/image size has a limit which varies based on the graphics card. Some older cards can only do up to 256x256 while more recently they go to like 2048x2048 or more. Ideally you'd select image sizes which are the maximum texture size or something smaller, but that obviously means that then your pixmaps have to be divided up into different sized chunks based on the image dimensions.
When you lock the image you are saying to the system that you want the handle to the image to be kept and not lost and that you want to change the image. If you change it, it HAS to be re-uploaded in full to the graphics card via the graphics bus. It will not detect the changes in the image to optimize the upload, it just sends the whole thing. The transfer from the pixmap in main memory to the image in video ram is what is causing the delay - and you should avoid having to make that transfer as much as possible. A pixmap is in main memory and cannot be displayed by the graphics driver, which is why you have to upload it whenever you've made some changes. However, like you said, if you compose your game world from various smaller images, each with its own smaller pixmap, then you only have to upload (when you unlock the image) the pixmaps that contain changes (ie mark them as dirty etc). You should also be only uploading enough images that are required to display a full screen of the game world - you do not need to hold the entire 4000x4000 texture data in video ram at all times, only the parts that are needing to be displayed, and you should then have the changing areas or the areas which are coming into view be reuploaded via unlocking those image. You have to use a pool of generic dummy images so you'll need to indirectly reference them.
To change the pixmap, use either readpixel/writepixel or use pointers in combination with PixmapPtr()
It is a good idea to make the higher-level multi-image type that you suggested. Then when you need to write to a given pixel it will abstractify the coordinates and write it into the appropriate pixmap.
It is also good to bear in mind that the maximum texture/image size has a limit which varies based on the graphics card. Some older cards can only do up to 256x256 while more recently they go to like 2048x2048 or more. Ideally you'd select image sizes which are the maximum texture size or something smaller, but that obviously means that then your pixmaps have to be divided up into different sized chunks based on the image dimensions.