I do not necessarily disagree with you.  I do not think that mimicking GLUT should be an absolute goal of
Freeglut, but I only mentioned it as a point of comparison.  With regard to my issue about capturing motion
events, I think there is some room for discussion.  While your suggestion would work, I have now decoupled
a motion event from the action that results from it.  If I have many other events coming in before my timer or
idle callback get called, the action caused by the motion event may no longer be appropriate.

I found a solution to my problem by modifying the event handler code in Freeglut (only will work on systems
I am the SysAdmin for ... not too many these days) in the routine glutMainLoopEvent (freeglut_main.c):

        case MotionNotify:

           /* New code starts here */
            if ( XPending( fgDisplay.Display ) > 0)
            { XEvent nextEvent;
              XPeekEvent(fgDisplay.Display, &nextEvent);
              if (nextEvent.type == NotionNotify) break;
           /* New code ends here */

            GETWINDOW( xmotion );
            GETMOUSE( xmotion );

            if ( window->ActiveMenu )

Adding the option that John mentioned, "GLUT_DELETE_SUCCESSIVE_MOUSE_MOTION_EVENTS",
should be trivial.

Thanks for your speedy replies.


On Mar 30, 2012, at 18:24, Jason Wilkins wrote:

You should not be doing so much work in an event handler.  Keep track
of the basic mouse movement and then do your work in a timer or idle

To the people who might respond that we should be like GLUT, if this
is indeed the original GLUT's behavior, then I disagree.  I really do
not like the idea of throwing out mouse events.  Like at all.

On Fri, Mar 30, 2012 at 3:13 PM, Allan Runkle <arunkle@pacbell.net> wrote:
Hello Folks,

I have written a small portable GLUT package that works on Linux, Windows & Mac OS.  For the Linux platforms,
I am using the Freeglut implementation.  I am now working on a capability based on the mouse movement and
have found a difference in the behavior between Freeglut & GLUT and an trying to find a work around.

Unfortunately, the callback I have for the glutMotionFunc has some time consuming work to do (at least with respect
to the mouse movement) and gets behind as more movement events are queued.  This results in very slow response,
as well as continued processing after the movement has stopped.  The same code run with the GLUT package does
not exhibit this behavior.  It appears that GLUT is throwing out all events received while processing the first one.
While I do not get as smooth an effect, I do get much better response to the mouse position.

Is there some way to to flush or ignore these extra events while I am responding to the first one?  I have tried turning
off the glutMontionFunc (setting the callback routine to NULL) while handling the callback, but this does not help.
I can think of elaborate ways to do this, but I was hoping of something a bit simpler (preferably a couple of API calls).

I am using a few different Linux distros, multiple verions of Red Hat enterprise versions as well as OpenSUSE. The
Freeglut versions also run the gambit for an old 2.2 to the current 2.8.  All seem to share this behavior.