I originally sent this message last Friday just before I left for the
weekend. It didn't make it because I typed in the wrong address.
For everybody else,
I sent a demo program to Richard off the reflector. Anybody else
who is interested in it can ask for a copy; given the timing I probably
won't get them out before Monday.
Yes, we are indeed on the same page. "Freeglut" calls the reshape
callback even though the second window is hidden; I believe GLUT does not.
As you say, the demo program does not crash because I don't dereference the
pointer, I only print its value.
I think your proposed fix is very reasonable and I look forward to
John F. Fay
From: Richard Rauch <sforge@ol...> - 2003-11-17 14:39:03
On Mon, Nov 17, 2003 at 08:23:54AM -0600, Fay John F Contr AAC/WMG wrote:
> I originally sent this message last Friday just before I left for the
> weekend. It didn't make it because I typed in the wrong address.
> For everybody else,
> I sent a demo program to Richard off the reflector. Anybody else
> who is interested in it can ask for a copy; given the timing I probably
[Aside to others: It demonstrates a bug he mentions in the bug database.]
> I think your proposed fix is very reasonable and I look forward to
> receiving it.
Sorry, I've been slacking off. But Chris has been doing good stuff.
(Somehow a few TABs worked their way (back?) into the code---possibly
my doing, possibly Chris's.)
I should write up a TODO list of things that I really want to do with
freeglut, since I'm now backlogged.
Should anyone else (Chris?) want to consider or implement my fix, I believe
(from memory) that my suggestion was to store the new window size in the
freeglut Window structure but postpone calling the reshape. Instead,
set a flag. In the redisplay-all function, if a window is visible and
has the reshape flag set, then reshape it and clear the flag (before
doing the redisplay).
This may reduce the number of reshapes that are done and will ensure
that only visible windows get a reshape event.
(GLUT docs specify that certain actions---including client-requested
reshapes---will not take place until the current event-processing pass
of glutMainLoop() finishes. So postponing the reshape event until just
before a redisplay should further improve our emulation on that point.
Though I don't know how readily an application can tell or care about this
fine point of GLUT compatibility. The bug that John found, however, really
needs to be addressed, IMHO.)
That's from memory, anyway. I'm not sure how much I trust my memory. (^&
My mind's a little too bleary at the moment, so I won't do it myself
for a little while, though it shouldn't be hard.
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/