The difference between a pixmap and an image is in what area of memory the data is stored, and what processor is being used to access it for rendering.
A pixmap in main memory can only be `drawn` to the display by the CPU. The data has to always transfer over the graphics bus which is somewhat slower than the CPU speed. The data is read and written by the CPU from main memory to video memory. This is always a relatively slow process because the BUS is slow.
An image is in video ram - somewhere that the graphics processor can `see`, so that it can read it as a texture and write it out as a visible image. It can do that really quickly and usually much faster than the CPU. BUT, this system is not designed to allow you to easily alter the texture that is being drawn.
The focus over the years has been really strongly on getting things to DRAW faster and hardly any focus on getting things to READ/CHANGE faster. Usually reading the contents of graphics and changing them is considered a non-realtime activity, since the main function of the GPU is to draw stuff and make it display.
The video ram is faster for the GPU to access since physically it is usually located close to the GPU and is not part of the main memory chips, and usually runs at a different speed. Video ram is kind of a `cache`, similar to a CPU cache, whereby things that are put into video ram can be accessed by the GPU most quickly, whereas things that need to be fetched from main memory (that are not cached), such as transferring new pixmap data, is always going to be slower. It's the same with CPU's, accessing stuff that is in the cache is fast, stuff outside the cache is as slow as accessing main memory with the CPU. Pixmaps are that slow offline memory and Images are the fast cached memory. You cannot and will not be able to find a way to make pixmaps as fast as images. The GPU is much faster at drawing pixels from an image, than the CPU is at transferring the pixels from main memory.
That said, in recent years additional features have been added to OpenGL to support things like render-to-texture, using at texture as a second back-buffer so that you can use the GPU to draw `changes` to it and then keep those changes for the future - so then you just draw the changed texture rather than having to keep transferring it from the pixmap. But BlitzMax does not support this by standard, you have to get into using GL extensions and writing your own GL code.
There is no fast way to draw an alpha pixmap. If you are going to insist on using a pixmap you have to at some point pay a time penalty for transferring it from main memory to video memory. It is faster to transfer it straight into a `texture` (image) and to let the GPU draw it to the screen, than to draw it directly to the backbuffer. Even the fastest drawing of a pixmap is usually more than 10 times slower than getting the GPU to draw it. The GPU is highly optimized to draw a huge number of pixels from `images` in a short time. Drawing a pixmap is a pretty archaic way to do things. Forget about it.
Focus on transferring as little of the changed pixmap to a set of images as infrequently as possible.
A pixmap in main memory can only be `drawn` to the display by the CPU. The data has to always transfer over the graphics bus which is somewhat slower than the CPU speed. The data is read and written by the CPU from main memory to video memory. This is always a relatively slow process because the BUS is slow.
An image is in video ram - somewhere that the graphics processor can `see`, so that it can read it as a texture and write it out as a visible image. It can do that really quickly and usually much faster than the CPU. BUT, this system is not designed to allow you to easily alter the texture that is being drawn.
The focus over the years has been really strongly on getting things to DRAW faster and hardly any focus on getting things to READ/CHANGE faster. Usually reading the contents of graphics and changing them is considered a non-realtime activity, since the main function of the GPU is to draw stuff and make it display.
The video ram is faster for the GPU to access since physically it is usually located close to the GPU and is not part of the main memory chips, and usually runs at a different speed. Video ram is kind of a `cache`, similar to a CPU cache, whereby things that are put into video ram can be accessed by the GPU most quickly, whereas things that need to be fetched from main memory (that are not cached), such as transferring new pixmap data, is always going to be slower. It's the same with CPU's, accessing stuff that is in the cache is fast, stuff outside the cache is as slow as accessing main memory with the CPU. Pixmaps are that slow offline memory and Images are the fast cached memory. You cannot and will not be able to find a way to make pixmaps as fast as images. The GPU is much faster at drawing pixels from an image, than the CPU is at transferring the pixels from main memory.
That said, in recent years additional features have been added to OpenGL to support things like render-to-texture, using at texture as a second back-buffer so that you can use the GPU to draw `changes` to it and then keep those changes for the future - so then you just draw the changed texture rather than having to keep transferring it from the pixmap. But BlitzMax does not support this by standard, you have to get into using GL extensions and writing your own GL code.
There is no fast way to draw an alpha pixmap. If you are going to insist on using a pixmap you have to at some point pay a time penalty for transferring it from main memory to video memory. It is faster to transfer it straight into a `texture` (image) and to let the GPU draw it to the screen, than to draw it directly to the backbuffer. Even the fastest drawing of a pixmap is usually more than 10 times slower than getting the GPU to draw it. The GPU is highly optimized to draw a huge number of pixels from `images` in a short time. Drawing a pixmap is a pretty archaic way to do things. Forget about it.
Focus on transferring as little of the changed pixmap to a set of images as infrequently as possible.