There's no problem with you creating a large pixmap, it can be pretty much as large as you like. The fastest way to modify pixels in it, even if it's just the alpha values, is to read the whole pixel using an Int Pointer, based on the PixmapPtr(), changing the component that you want to modify, then writing it back to the same pointer. Alternatively you can use ReadPixmap and WritePixmap (or is it ReadPixel and WritePixel).
Like Dreamora says, it is going to consume quite a few megs of ram to keep a pixmap that large - but hey, that's your decision, and on today's machines people tend to have a lot more ram than they used to.
What you then want to do is treat your pixmap like a pool of image data (for example, similar to the megatexture system which is becoming popular right now) - where you spool small sections of image from your pixmap into images in video ram on an as-needed basis, for display purposes only. The fastest way to do that is create empty textures and then upload the texture data, using the appropriate values to read a window in your pixmap. You should not need to be grabbing whole sections of pixmap and pasting it back into a pixmap just to get the window functionality.
Then when you render your display you are pulling from the images that you've uploaded previously, reusing those that were on-screen in the last frame, and those which you just pre-uploaded for the areas of screen that are just off the display. Then you only need a little more than 1 screen's worth of images consuming video ram. It's much faster to draw an image, and to re-use an image that you uploaded some time previously, rather than to upload whole pixmaps of data every frame for the whole display. You will still take a performance hit for transferring pixmap data to the texture(s) but nowhere near as much as drawing entire pixmaps. And then you can render with alpha blending.
Like Dreamora says, it is going to consume quite a few megs of ram to keep a pixmap that large - but hey, that's your decision, and on today's machines people tend to have a lot more ram than they used to.
What you then want to do is treat your pixmap like a pool of image data (for example, similar to the megatexture system which is becoming popular right now) - where you spool small sections of image from your pixmap into images in video ram on an as-needed basis, for display purposes only. The fastest way to do that is create empty textures and then upload the texture data, using the appropriate values to read a window in your pixmap. You should not need to be grabbing whole sections of pixmap and pasting it back into a pixmap just to get the window functionality.
Then when you render your display you are pulling from the images that you've uploaded previously, reusing those that were on-screen in the last frame, and those which you just pre-uploaded for the areas of screen that are just off the display. Then you only need a little more than 1 screen's worth of images consuming video ram. It's much faster to draw an image, and to re-use an image that you uploaded some time previously, rather than to upload whole pixmaps of data every frame for the whole display. You will still take a performance hit for transferring pixmap data to the texture(s) but nowhere near as much as drawing entire pixmaps. And then you can render with alpha blending.