CODEWITHSUNDEEP
c++winapigraphicsbitmapgdi
Erwin
Erwin

Reputation: 188

Real time drawing in GDI

I'm currently writing a 3D renderer (for fun and research), so I need a way to draw my framebuffer to a window. Since I'm doing all of my calculations on CPU, the drawing needs to be as fast as possible.

One of my goals is to use no existing graphics library (OpenGL/DirectX) so the drawing to the screen is pure Win32. In my research I've found a couple of ways to create and draw bitmaps and now I'm looking for the best one.

My current implementation uses a bitmap created with CreateDIBSection(), which is drawn to my window DC using BitBlt().

CreateDIBSection() give me a pointer to my bitmap bytes so I can manipulate it without copying. Using this method I achieve an update rate of about 260 FPS (without any rendering done). This seems a bit slow, so I'm looking for optimizations.

I've read something about that if you don't create a bitmap with the same palette as the system palette, some slow color conversions are done.

How can I make sure my DIB bitmap and window are compatible?

Are there methods of drawing an bitmap which are faster than my current implementation?

I've also read something about DrawDibDraw(), can anyone confirm that this is faster?

Upvotes: 1

Views: 1901

Answers (1)

Adrian McCarthy
Adrian McCarthy

Reputation: 47962

I've read something about that if you don't create a bitmap with the same palette as the system palette, some slow color conversions are done.

Very few systems run in a palette mode any more, so it seems unlikely this is an issue for you.

Aside from palettes, some GDI functions also cause a color matching conversion to be applied if the source bitmap and the destination have different gamuts. BitBlt, however, does not do this type of color matching, so you're not paying a price for that.

How can I make sure my DIB bitmap and window are compatible?

You don't. You can use DIBs (which are Device-Independent Bitmaps) or compatible (device-dependent) bitmaps. It's possible that your DIB bitmap matches the current mode of your device. For example, if you're using a 32 bpp DIB, and your display is in that same mode, then no conversion is necessary. If you want a bitmap that's guaranteed to be in the same mode as your device, then you can't use a DIB and all the nice properties it provides for predictable pixel layout and format.

Are there methods of drawing an bitmap which are faster than my current implementation?

The limitation is most likely in getting the data from system memory to graphics adapter memory. To get around that limitation, you need a faster graphics bus, or you need to render directly into graphic memory, which means you'd need to do your computation on the GPU rather than the CPU.

If you're rendering a 1920 x 1080 pixel image at 24 bits per pixel, that's close to 6 MB for your frame buffer. That's an awful lot of data. If you're doing that 260 times per second, that's actually pretty impressive.

I've also read something about DrawDibDraw(), can anyone confirm that this is faster?

It's conceivable, but the only way to know would be to measure it. And the results might vary from machine to machine because of differences in the graphics adapter (and which bus they use).

Upvotes: 2

Related Questions