Printable View
I need to have many images cached in memory so I can blt them with high performance. Currently they're held in DCs.
I have to decode these images manually. So would editing the memory of the surface directly, then having memory-based surfaces as caches, instead of DC's be better?
I don't see how blting the DC to the surface, then to the primary would be faster.
Wouldn't I also have to do memory checks to see how much I can store in memory?
It is fastest to let the API decode. I found this out with a recent project that I pasted some CreateDibSection code in. There is a CreateBitmap function that sets up information for bitblt, and it is very fast. I am a 'fan' of manipulating my own data directly, but I wonder how direct it is, or I wonder if the data access allowed by APIs moves image information to a slower section of memory, perhaps in RAM, which is different from video memory. Basically what happened in this one project is that everything was blitting about 112 fps, and then I added CreateDibSection 'so I could have direct access', and the framerate dropped to 35fps average max. It's closer to 15 fps. I have not yet accessed any information. This is working with 32 bit data on a 900mhz system w/ a g-force 2 and a backbuffer of 640 x 480.
The image format is custom. There is no API to create it for me.
It's rather irrelevant at the moent as my function decodes them insanely fast using a decode to DIB then to DC method. The problem is all the blting, with transparency and translucency.
I may have just had an insight. Device-dependent bitmaps. I don't know much about ddbs so 'permit me' to do some research.
My images are currently in DDBs.
ok. thanks, and sorry I couldn't help ya.