Re: [Freeglut-developer] Bug in current CVS version

[Richard R. <sf...@ol...>]

On Wed, Oct 15, 2003 at 11:06:09AM -0500, Fay John F Contr AAC/WMG wrote:
> I agree that disabling all the callbacks of a window that is being destroyed
> is a Good Thing.
> 
> I also agree that we should probably not depend on nulls being zero or on
> the structure being nothing but pointers and padding.
> 
> I further point out that the idle callback is a global callback.  It will
> not be disabled when a window is being destroyed.  Therefore we will still
> need the earlier change about
> 
> if ( event )
> {
>   while ( event )
>   {
>     <retrieve and process event>
>   }
> }
> else
> {
>   if ( idle callback )
>     invoke idle callback
> }

A few responses:

 * This started because of glutPostRedisplay() was failing, yes?
   But we can make it tolerate being set for a window that is
   *dying* but not yet completely dead.

 * The real code won't be so clean as the pseudo-code suggests
   because we don't have one general class of "events".  We
   have window events (mouse, keyboard, resize, ...).  We have
   timer events.  We have joystick events (basically specialized
   timers; the API keeps us from ever doing anything different, so
   we should really just roll the joystick "events" into the timer
   list for simplicity, as discussed before).  We have redisplays.
   And we have idles.

 * I'm not 100% clear what your remaining objection is to idle's
   behavior.  As I noted way back when I changed this to a loop,
   there was already the possibility to invoke several events
   through one pass of glutManLoopEvent().  (E.g., joystick and
   timer, or multiple timers, ...)  Whatever your objections to
   idle, won't they *still* apply to other events?

 * If idle is truly a special case here, maybe it would be simpler,
   and cleaner, and more logical, to remove idle "events" from
   the glutMainLoopEvent() and do them in glutMainLoop()?
   This is defensible, I think, since only those who call
   glutMainLoopEvent(), themselves, could detect the difference,
   and I don't see any reason why *they* would need a GLUT idle
   function.

   It is logical since idles aren't really events, per se, but
   are rather "non-events" in a sense.

   It may be cleaner since we can perhaps arrange to do this
   in the glutMainloop() where it won't be a problem.  Say putting
   this in, in place of the main loop that's there now:

     while ( GLUT_EXEC_STATE_RUNNING == fgState.ExecState )
     {
       glutMainLoopEvent () ;
       if ( fgStructure.Windows.First == NULL )
         fgState.ExecState = GLUT_EXEC_STATE_STOP ;
       else
       {
         if ( fgState.IdleCallback )
           fgState.IdleCallback ();
         fgSleepForEvents();
       }
     }

   ...though since I don't see the idle as a special case, I really
   don't care for this change.  I suspect that whatever problems
   there are with idles will also exist with other cases,
   and I'd like to deal with them all at once.

 * I still do not see why we don't just exit() when the window
   closes if the program hasn't requested continuing execution.
   If the user has requested this, then the user is responsible
   for catching window destruction.  if the user hasn't requested
   this, then we can just exit.

   Allusion was made to dealing with cleaning up allocated resources.
   I recall some mention in the GLUT docs/notes about what they do
   to get atexit() to work in that case.  (Apparently, Microsoft
   has multiple versions of the C run-time library (crt as it's
   called on some systems), and you have to know which one to link
   against in order to get atexit() to work as it should.  Otherwise,
   GLUT/freeglut will call the "wrong" exit(), which will share data
   with the "wrong" atexit(), and the client program's atexit()
   request will be ignored.)

   If I recall the GLUT notes correctly, their options were to either
   have applications link against the same crt as GLUT assumed
   (alternatively, they could provide different GLUT "models"
   for each crt), or they could devise a way around this.  They
   apparently found a way around it, as could we.  (Our own
   atexit() and/or exit(), perhaps?)

   If we just exit() when we are done, I suspect that whatever
   your complaints are with glutMainLoopEvent() would go away.
   And similar objections for other event types would go the same
   route.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/