Back to General and Gameplay Programming

Win32 Message Pump and OpenGL - rendering 'pauses' while dragging/resizing

shurcool · 2008-03-29T12:28:47

I've often seen many small OpenGL demos/apps that would sort of 'pause' whenever you drag the Win32 window around, or resize it, etc. The rendering basically comes to a halt during the time the mouse button is pressed down. There were a few rare examples that didn't exhibit that behaviour, and continued to update the frames even as its window was dragged/resized. I've never paid much attention to this because it was irrelevant at the time. However, I now have acquired a requirement to eliminate this behaviour for my networked game client in Windows. Searching around provided with me with surprisingly little info on the subject, but it seems the problem has to do with the Win32 message pump basically blocking the main window's thread when you start dragging/resizing your window, preventing the thread to execute normal rendering updates. From what I was able to gather, the only way to circumvent this issue is to create a 2nd separate thread solely for OpenGL rendering. Is that correct, or is there any other way (keeping rendering in main thread)? Currently, I have the window created and all my game logic/rendering in the main thread. The problem is, I don't want the user to be able to 'pause' the game logic and prevent it from running normally. Is my only solution to move it out of the main thread containing the win32 message pump? If so, should I take rendering along with it, or will rendering from a separate thread cause issues/problems and not worth the trouble? Or is it ok if I do it right? Another thing to mention is I'm currently using the GLFW library to handle the window creation for me, and since it's portable, it doesn't directly allow me to get the window handle, DC or rendering context (all that win32 stuff you deal with when creating a window yourself), and based on the only example I was able to find, you need to access the RC in order to render from another thread. A multithreaded OpenGL example It seems I would have to modify the library slightly to allow for that, but I don't have a problem with doing that for now if it's necessary. If anyone could point me to some articles or any info on this subject, I'd greatly appreciate it. Especially if anyone has done something like this using GLFW - that'd be just too perfect. Thanks, and sorry for a long post. P.S. I've tried my game on Linux, and it doesn't have that problem there. So I only need to get it fixed for Win32.

General and Gameplay Programming Programming

Started by shurcool March 25, 2008 11:06 AM

15 comments, last by Evil Steve 16 years ago

MJP

20,295

March 28, 2008 11:02 AM

It wasn't an argument and I'm not sure why you're turning this into one. I simply told you the standard method for overriding the default behavior of the windowing system. If you don't like the consequences of doing it in this particular situation, don't do it.

The Blog | The Book

shurcool

439

Author

March 28, 2008 11:30 AM

Sorry, I'm still a little on the edge after finding out all that stuff about Win32 code, and I jumped the gun when your post somewhat seemed to defend it like "there's nothing wrong with Win32 msg pump design, just do this and everything'll work the way you want it to."

Anyway, Windows is a reality we live in so I'll just have to face it. >.< I just kinda had better expectations for it before (I was never one of those guys who always dissed it).

Bob Janova

769

March 28, 2008 06:50 PM

In my opinion, your game engine loop shouldn't be tied to your rendering loop anyway. So sure, rendering stops when the window is being resized, but your game logic shouldn't. That is done by having the game logic in a separate thread.

shurcool

439

Author

March 28, 2008 08:41 PM

Yeah, that's kinda what I'm considering at this point, however it's still not an ideal solution, as the input polling has to stay in the main thread. I'll have to think more about this.

jpetrie

13,220

March 28, 2008 10:41 PM

FWIW, some of the details of what DefWindowProc will do under the hood are spelled out in the documentation for the messages themselves versus that function specifically. Additionally, DefWindowProc is (like some other aspects of the API) not spelled out in exact detail for a reason: you aren't supposed to care, so that the development team is free to make tweaks without breaking assumptions you may have made on implementation details.

After all, they have enough of those hacks in the OS to cover the asses of bad developers already.

MJP

20,295

March 29, 2008 12:24 PM

Quote:Original post by jpetrie
After all, they have enough of those hacks in the OS to cover the asses of bad developers already.

Do you read Raymond Chen's blog as well?

The Blog | The Book

Evil Steve

2,021

March 29, 2008 12:28 PM

Quote:Original post by shurcool
Yeah, that's kinda what I'm considering at this point, however it's still not an ideal solution, as the input polling has to stay in the main thread. I'll have to think more about this.

What sort of input polling? If you just record mouse movement, mouse button presses and keyboard presses, you can just record them in an array of volatile bools and ints. Access to them should be atomic, so there shouldn't be any problems accessing them from two threads.

Win32 Message Pump and OpenGL - rendering 'pauses' while dragging/resizing

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Win32 Message Pump and OpenGL - rendering 'pauses' while dragging/resizing

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines