When you use CreateImage() or LoadImage() or, I think there's also something like bglTextureFromPixmap() or something like that .. .When you use those, what you're doing is `uploading` an image into videoram. They then sit there in video ram for as long as the OpenGL context is present, or until you delete them. In some cases if you don't have enough video ram to hold all of the images that you are trying to use at once, it may spool some of the lesser used ones off to main memory and swap back and forth to try and accomodate you, which of course produces slowdown.
When you use DrawImage you are just taking the pixels from one location in video ram, pushing it through the OpenGL pipeline and squirting it out the other end usually into the backbuffer, which is also in video ram. I would say the front buffer is also in video ram, although in window mode I'm not sure how that exactly works.
If your hardware doesn't support any implimentation of OpenGL routines, ie it's just sitting there as a basic display device and not much else, you might have an OpenGL driver which does everything in software. In that case you might find that the images are `uploaded` from main memory TO main memory. The OpenGL system will then likely run at the same speed using DrawPixmap() as it does using DrawImage(), because both are using the CPU. In most cases your hardware and driver and OpenGL implimentation will support using the hardware to do stuff, in which case DrawImage is a lot faster.
At the moment we don't have functionality to get the address in video ram of the OpenGL buffer or images. Btw Images are the same thing as `textures` - ie uploaded graphics stored in video ram. OpenGL can only USE graphics that are considered `uploaded`, ie usually in video ram. It isn't usually able to work with graphics in main memory. You can transfer the backbuffer to/from main memory but it uses the CPU and is generally slow. Only when the image is stored in video ram can OpenGL use it to draw to/from. Pixmaps are a BlitzMax-invented object, which is alluded to in the OpenGL documentation, to provide `offline` CPU-based handling of graphics data that isn't `active` in the OpenGL system. Because OpenGL *manages* the textures/images, BlitzMax currently doesn't very well know what it's doing with it. Once Max asks OpenGL to do something, it's kind of like passing the baton. OpenGL then does its thing, or tries to, and returns to BlitzMax.
So at the moment we don't really have a way to get that memory address, and it may change every time you do a Flip. You can `lock` an image, which basically means download it to main memory, work on it as a pixmap, and then re-upload it. It would be GREAT to be able to get a lock on the backbuffer, plus get the actual memory address of the locked graphic. I don't think we currently have access to that.
I had been thinking that you could draw a small image to the backbuffer, like just an 8x8 image. Then you could get the base address of video ram and do a `search` through all of video ram trying to find the image data. Then if you find it, you might have the base address of the backbuffer. But I'm sure the memory may move a lot and is unpredictable, plus I don't really know what format the data is stored in.
|
