Odd Pixmap better than TImage boost

BlitzMax Forums/MaxGUI Module/Odd Pixmap better than TImage boost

Snarty(Posted 2010) [#1]
Soo, I come back after a million years and fire up BMax to start development on a certain app.

Ok, after much head-scratching, reading of these forums and some appalling render times. I needed to throw away the core methods I used in Blitzplus. Here's what I found, not sure if this is indicative to my system or OpenGL in general.

To start with I was using a TImage as a main storage type for image editing with a matching canvas size. This method got very slow very fast.. 2048x2048 and above, and failed over 10,000x10,000 sized images (approximate). I understood there would be canvas limitations but wasn't expecting the poor render times.

Time to switch to a Canvas as a portal only, used to display the image and therefore only ever as large as the client area. To my surprise this had no effect on rendering, but did remove the upper limit on size. Just got slower and slower the larger the image.

So. With the above in mind I just gave in and ignored what seems a hate for pixmaps and went that route instead. I now use a pixmap for all image storage and layer building with no TImage for actual storage. The Canvas is now always the same size as the users desktop. Purely used for pre-rendering / rendering. This may change.

What I do now is upload portions of a pixmap in to a fresh TImage each frame that needs rendering, and/or pre-rending for using GFX card based effects (blending etc). To my complete and utter surprise this is lightning fast no matter the size of base image or size of the client area.

So, just shocked is all, and am I heading down the right path? Would this behaviour be pretty much linear across all platforms / units (ignoring crappy old machines that should be burned).

Brief Overview of my findings.
TImage --> DrawSubRect --> Canvas (SLOW)
TPixmap --> TPixmap.Window --> Upload to TImage --> Canvas (UBER FAST)


Mr. Write Errors Man(Posted 2010) [#2]
Images are kept on the vid memory, pixmaps are not. Considering that 10000x10000 image takes around 500 megs of video memory (depending on mip mapping and such), it's no wonder it becomes slow.


Snarty(Posted 2010) [#3]
yeah, the extremes I expected some sort of issues, but @ 2048x2048 I thought it would have been possible to hold in video memory. I was wrong. lol

Besides I always have been a fan of storing image data in system memory over video memory for GUI stuff.


ima747(Posted 2010) [#4]
There are limits to what a specific card will hold in in it's vram. I think above 1024x1024 it starts to get hazy as to weather it will allow it in one block or not, even on some "newer" cards. It's not so much the capacity of the card, as the design of the drivers.

The only real problem I think you might have with using pixmaps directly is that the pixmap drawing functions to the best of my understanding are very very driver specific, meaning there's a fair chance that for example they may work fine on one system but may be a little weird on another system with a different driver revision, or a different version of DX etc. I personally haven't run into this problem, and it's more likely related to more legacy systems and stuff with crap cards, but still something to be aware of when you get to testing.


Snarty(Posted 2010) [#5]
Yeah, I did read about the pixmap > driver issues. But, luckily I don't use any pixmap drawing functions. All rendering is done via TImage still, I just upload from the pixmap/pixmap window to an image each time any drawing is required. So far, in testing, this seems fast enough.

Thanks for the feedback.