Why separate pixmaps and images?
BlitzMax Forums/BlitzMax Beginners Area/Why separate pixmaps and images?
| ||
| I'm trying to understand from the documentation why there are `images` and `pixmaps` as distinctly different entities. It describes pixmaps as being used when you want to modify the image, whereas images are used for static images that aren't going to change. Does this somehow make the coding faster for images versus pixmaps, or does it store the images in graphics memory instead of main ram? Seems you can draw images and pixmaps to the backbuffer either way. ???? |
| ||
| Images are not CPU addressable. They are designed for fast rendering - eg: GLMax2D stores them as OpenGL textures and GL textures are not 'visible' to the CPU. Pixmaps are designed to be addressable by the CPU and are a form of 'intermediate' format used by loaders and for general pixel manipulation. Pixmaps will typically be much slower to render. |
| ||
| Ok. Now from what I gather from reading through the whole sections on Max2D and Pixmaps, images are, in general, image `objects` which contain image data plus some other data, whereas Pixmaps are more like JUST the data, or to only access the image data? I figured the images are probably somehow separated from the main memory or at least the CPU like you say. So if I want to modify a bitmap with the CPU and some kind of pixel-manipulating programming I use a pixmap. So how come the pixmaps are slower to render to the backbuffer? Do they have to be passed over to the video ram before being rendered? (I'm thinking back to the old days of Mildred fastram gfx trying to get it to display on a graphics card). What command(s) would I use to most quickly render a rectangular portion of a very large image to the backbuffer? And why, if the pixmaps are meant to be the editable ones, do you allow DYNAMICIMAGE as a flag for images? You can obviously lock an image and edit it in some way? What happens when you lock an image? I can see it returns a pixmap, does it transfer all the image content to ram first and create a new pixmap object (like a download-from-video-ram)? Thanks for responding. |
| ||
| As far as I understand: Pixmaps = You can manipulate pixel-by-pixel and perform very low-level operations. Images = Pixmaps converted to GL textures or some other format for fast rendering. |
| ||
| What would be great would be to see a diagram of where in what system all this stuff is stored and what steps are taken to convert and move stuff around, so that we know how to tweak our code and to keep these things in mind so that we can create an efficient engine. Apparently pixmaps are slow to render, yet they can be locked just like images can be locked. What happens when images are locked? These questions and more on next week's episode of ...... ??? |
| ||
| So how come the pixmaps are slower to render to the backbuffer? Do they have to be passed over to the video ram before being rendered? Yes, images are ready for the video card and its memory, which means (I think ) they could also be compressed. This also means more speed. Where as pixmaps are only CPU addressable, which is going to make them slower. I generally use them for image construction, then copy the pixmap to an image via LockImage. See this example: http://www.blitzbasic.com/Community/posts.php?topic=41440 I think there is a faster way to do this but you will need to keep track of the pixel format for the PixMap. L8r, |
| ||
| Hmm yea, but it just seems a bit wasteful to have to copy the pixmap to video memory into a texture and then render the texture - how about copying directly from the pixmap into the screen display? I guess that's out of the question eh? |
| ||
| My understanding is that OpenGL won't let you do that (all images have to be drawn as textures), and it doesn't provide direct access to the backbuffer memory either. |
| ||
| I guess there's the DrawPixmap command, but probably it converts to an image (texture) first before getting drawn? Mr Flameduck helped come up with an alternative solution for what I needed, for using a big superbitmap as a scrolling background ... by breaking it up into smaller tiles and only updating (to images) the parts of the pixmap that change and are viewable. It's one solution that is probably quite elegant given the circumstances. |
   |