Sign in to follow this  

Blitting in Glut Window

This topic is 4354 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi people, I have a question, how can I Blit a bitmap in a glut window? My system is Window, so I'm using wglGetCurrentDC() to take de device context, and Blitting in this device, but there is a problem, the BitBlit command is before glutSwapBuffers(), so the bitmap blinks, I think glutSwapBuffers() changes de visible device context, how can I Blit in the "future" dc? Thanx

Share this post


Link to post
Share on other sites
Quote:
Original post by kreh
Hi people, I have a question, how can I Blit a bitmap in a glut window?
My system is Window, so I'm using wglGetCurrentDC() to take de device context, and Blitting in this device, but there is a problem, the BitBlit command is before glutSwapBuffers(), so the bitmap blinks, I think glutSwapBuffers() changes de visible device context, how can I Blit in the "future" dc?

Thanx
Since you are using OpenGL (through GLUT) you should use OpenGL's method for "blitting." glDrawPixels does what you want (more information in the Drawing Pixels, Bitmaps, Fonts, and Images Chapter of the Red Book). It may not be as fast as you would like though.

You can get significant speed ups if you create a texture from the bitmap and draw a textured quad instead of copying the bitmap directly to the framebuffer via glDrawPixels. If you want to go the texturing route, read the Texture Mapping Chapter in the Red Book. I recommend to read and understand all of the previous chapters in the Red Book first though. Same goes for the previously mentioned chapter on pixel operations.

EDIT: Just to be more precise... In a double-buffered OpenGL context, the framebuffer consists of front and back buffers (among other things), which is all contained inside the OpenGL rendering context that GLUT creates for you, and the rendering context belongs to the windows device context. So the problem with BitBlt is not that it's blitting to the wrong DC, but to the wrong buffer. I'm not too well versed in the inner workings of BitBlt, but you can think of it as blitting onto the front buffer. This is obviously bad because, as you found out, when you swap the buffers what you previously blitted gets overwritten. So what needs to be done is to blit onto the back buffer (not a separate DC like you stated in the opening post), which I'm pretty sure you can't do with BitBlt (not positive though). glDrawPixels defaults to copying pixels into the current draw buffer, which defaults to the back buffer in a double-buffered setup.

But if you want to do this as fast as you can then texturing and the GL's 3D pipeline is the way to go.

I hope that edit helped more than it hurt. [grin]

[Edited by - Kalidor on January 11, 2006 3:31:35 PM]

Share this post


Link to post
Share on other sites

This topic is 4354 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this