OK, it's been two and a half months, but I have a LONG memory. (So
does the "Follow-Up" list in my e-mail program.)
I've tried taking out the immediate call to the display callback
from the "WM_CAPTURECHANGED" branch of the Windows event handler and the
problem does not recur. I'm not sure what other changes have been made to
"freeglut" since the bug came up, but it seems to have been fixed elsewhere.
For people who don't know what I am talking about (which probably
includes Richard and may include me, if I am answering the wrong thing
here), when I ran the "Blue Pony" GLUT demo using "freeglut" I would stop
the pony from moving by pressing the space bar. Then if I used the mouse to
increase the size of the window in either or both directions (by clicking on
the corner of the window and dragging away from the center) only the new
part of the window would be redisplayed to. The old part of the window
would be unchanged until I started the pony moving again or until I shrank
the window somewhat. But the problem seems to have gone away. I am marking
the feature as "Closed."
John F. Fay
From: Richard Rauch [mailto:sforge@...]
Sent: Wednesday, April 14, 2004 12:47 PM
To: Fay John F Contr AAC/WMG
Anyway, it sounds like the window-resize event is being botched. One
thing I note (on this tiny 80x25 text terminal; (^&) is that you
dispatch the redisplay callback *directly* and *immediately* from the
resize (WM_CAPTURECHANGED). This brings two thoughts:
* GLUT promises to delay and coalesce those. While firing them off
early isn't normally harmful, why not simply do the equivalent of
* Delaying the callback (or indeed changing it to just do the Reshape
callback and let the *client* decide when, or if, to do a
glutPostRedisplay()) might solve the problem.
Possibly removing the client callback (I don't see a reshape
at that point in the WIN32 code, so maybe you do not need one)
The symptoms that you describe sound like an effect that the Amiga
windowing system (Intuition) offered: When your window was partially
damaged, you were given a list of damaged areas. You could explicitly
tell the OS to take that list back and use it to clip/cull graphics
that you might use in redrawing the window. When you were done, you
told Intuition, and it would then remove the masks.
It sounds like WIN32 is automatically doing such a thing during the
resize event to let you fill only the new area. So you may need to
somehow kick out of that mode before invoking a client refresh.
Also, WM_PAINT seems to have a similar problem of forcing a redisplay
*immediately*. It also surrounds the operation with a BeginPaint()
and EndPaint(). Perhaps if you at least swapped the redraw with one
of the *Paint() functions, it would help?
(I'm not sure if it's safe to postpone the real redraw event from
WM_PAINT. I seem to recall that the WIN32 redraw sequence is a
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/