It looks as if it is the case that a window that is
both not visible and with apending redisplay can consume
100% of the CPU while doing nothing.
(oghRedrawWindowbyHandle() skips the window if it is not
visible, leaving the Visiblee flag set to false not
calling the client handler, so the flag stays set and
OpenGLEAAN ever sleeps.)
Checking {window->State.Visible} when seeing if there
are pending redisplays seems like a possible solution.
However, doing so may result in redisplays being
unexpectedly delayed. It might less violate the
principle of least surprise---as well as result in
simpler code---to simply ivoke the client redisplay
callback even on hidden windows. A "dumb" client may
try to redraw its geometry, but this should be a quick
process if the window is completely obscured. Only if
the program calls glutPostRedisplay() during the process
of redisplaying---or from an idle callback---would the
library waste CPU time, then; and in that case, the CPU
[ab]use would be reasonable to expect.
The current behavior is a bug; I'm undecided about the
best fix, however, so I'll leave this bug report here,
open, for a while.
Right now, there is no way for the client application to
protect---or extricate---itself from this situation.
Log in to post a comment.
