#87 [WIN32] Incorrect message sleep argument causes odd delays

moderate (59)
Will Bryant

The fghSleepForEvents function in freeglut_main.c
contains the following call:
MsgWaitForMultipleObjects( 0, NULL, FALSE, msec,
which, since no event objects are specified, sleeps until
a) the timeout (msec) expires; or
b) An input, WM_TIMER, WM_PAINT, WM_HOTKEY, or posted
message is in the queue.

This should instead be
MsgWaitForMultipleObjects( 0, NULL, FALSE, msec,
which would instead sleep until
a) the timeout (msec) expires; or
b) Any message is in the queue.

The difference is that the current code will ignore any
window messages that are _sent_ (as opposed to
_posted_) except those listed. This causes several
strange things to happen when a freeglut application is
running; for example, on my WinXP desktop,
1. If I right-click on the taskbar button for the
application, the menu will not pop up until I happen to
move the mouse over the application window.
2. If I try to open a file from Explorer (even one that
is not associated with the freeglut application), there
will be a 1-2 minute pause before it opens.
Both of these rather random oddities are simply because
freeglut isn't processing normal window messages until
it happens that another message is posted through, at
which point it wakes up and runs the message queue and
everything happens.

So the fix, changing QS_ALLEVENTS to QS_ALLINPUT,
simply changes the wait function behaviour so that it
will wake up when any messages are sent or posted to
the queue.

In fact, I suspect that this was in fact the original
intention of the code author - QS_ALLEVENTS and
QS_ALLINPUT are not very well-chosen names, they'd have
been more accurate the other way around IMHO.


  • John F. Fay

    John F. Fay - 2006-09-21
    • status: open --> closed-fixed
  • John F. Fay

    John F. Fay - 2006-09-21

    Logged In: YES

    I implemented it and ran a quick demo program. I saw no
    difference so it appears at least that nothing broke.

    - John


Log in to post a comment.