Hi Rob,
Your 3D animation
with a timer looks nice.
Yet ...things3DV.exe also has a bomb in it, which is its
OpenGL test/STOP button.
People, do not press it! It freezes my computer to total unresposiveness and the only way out is a cold reboot!
In a GUI applucation, Windows must have its own time slot to process window(s) messages in the respective callback(s). Every Windows version has a fixed period (XP, the longest, 7+, the shortest) within which the system waits for a return from the callback -- not more than just a few seconds. If a window message goes to the callback but there's no return from it for a longer time than this fixed period allows, the entire application is marked as "unresponsive" and its execution is forcibly interrupted by the system.
That said, a Windows GUI app must not perform any activity running in a tight Do/While/For loop unless this loop:
- either is very short, i.e. shorter than the aforesaid fixed period
- or has some statement that enforces the time slice in which the app can consume and execute the messages that have been accumulated in the message queue by that time.
Such enforcement is usually done with the help of
DoEvents statement in the languages that support it, e.g. VB or FBSL, or its equivalent in those that don't.
The simplest
DoEvents implementation would be a simple
While statement as shown below in pseudo-code:
(do not use If instead of While because message handling must at all times have higher prioriry in a GUI program than any other task!)While PeekMessage(PM_REMOVE)
TranslateMessage()
DispatchMessage()
WEndThe entire
DoEvents implementation in the
VB6 sources counts more than a thousand lines of C++ code!
Clearly enough, any form of
DoEvents will slow down the loop but this is a natural trade-off for the pleasure of working in a civilized GUI environment rather than in a medieval console/terminal/punchcard/abacus/whatever.
Your OpenGL test runs in a
Do/Until loop that doesn't allow Windows to execute its pending
WM_ messages. OpenGL render tasks do not and cannot substitute the genuine callback in an implementation like this.
I believe your Linux Wine grayouts are of the same nature as my stall/reboot and are caused by the phenomena that I've described above. Wine is supposed to mimic Windows as close as possible after all, isn't it?