PDA

View Full Version : OpenGL and callback function



changhai
12-03-2002, 04:13 PM
Sorry to bother experts here. This is really a beginner level question, but I failed to get any reply from the beginner's forum. The problem is as follows:

In a normal hello world Win32 program, the drawing is usually done in the callback function (under the handler of WM_PAINT message), but in some OpenGL sample code I saw, the drawing is done in the message loop (located in the WinMain function). Is this difference radical? Or is there an equivalent way of doing OpenGL drawing in the callback function? Thanks a lot for help.

Changhai

Korval
12-03-2002, 04:29 PM
It depends on the application.

A fullscreen app doesn't really care about WM_PAINT messages; it draws when it wants to.

A windowed app, however, should respect Windows to an extent. You can draw whenever you want, really. The difference is that, if you're not going to draw when you get a WM_PAINT message, I believe you have to call BeginPaint/EndPaint anyway in your WM_PAINT handler.

Usually, if I'm animating something (like in a demo, for example), I ignore WM_PAINT messages. But, if I'm writing an interactive program (say, a model viewer), I tend to just call the draw function from my WM_PAINT handler.

jwatte
12-03-2002, 05:36 PM
An OpenGL program that's a CAD drawing program or model editor or something like that, can and should draw in response to the paint callback.

An OpenGL program that's a game (and, actually, a GDI program that's a 2D game, too :-) usually wants to run as fast as possible, and render and step phyics as much as possible. Trying to post redraw events and then waiting for them just slows you down -- if you're going to be rendering as fast as you can anyway, you're better served by ignoring the repaint event.

Robbo
12-05-2002, 08:08 AM
I do this in my active-x control - only problem is, CPU is about 80%, even when the control is paused. When pausing the app, you want to revert to the WM_PAINT message because a user may well pause it because they want more clocks elsewhere in the system.

Of course, this doesn't matter in full-screen so much - unless you allow minimize to task-bar from fullscreen, in which case you should really automatically pause the control.