Re: [Freeglut-developer] glutMotionFunc

[Allan R. <ar...@pa...>]

On Mar 31, 2012, at 02:47, John Tsiombikas wrote:

> On Fri, Mar 30, 2012 at 07:50:21PM -0700, Allan Runkle wrote:
>> 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 */
> 
> There's an Xlib mechanism to do this sort of thing:
> 
> XEvent xev;
> while(XCheckIfEvent(fgDisplay.Display, &xev, match_evmotion, 0));
> 
> static Bool match_evmotion(Display *dpy, XEvent *xev, XPointer arg)
> {
>    return xev->type == MotionNotify;
> }
> 

Not familiar enough with that routine, but a quick read on the routine sounds like you could get and then
process events out of order.  A future motion event could be processed before an earlier mouse button
press or release (as example).  I admit, it is or should be a very small window of vulnerability.

Also, after re-looking at where I placed my code segment, that is in the wrong place.  There is code in the
motion event handler that deals with menu actions (haven't used that capability yet, but looking forward to).
The code to "skip" motion events should probably be as close to the INVOKE_WCB motion calls as possible.


>> Adding the option that John mentioned, "GLUT_DELETE_SUCCESSIVE_MOUSE_MOTION_EVENTS",
>> should be trivial.
> 
> If you are all in agreement I'll go ahead and do this change. But let's
> choose a shorter name please :) At the very least let's drop the MOUSE_
> part from the name.
> 

How about "GLUT_SKIP_STALE_MOTION_EVENTS".

Again, thanks for the quick look into this issue.

Allan Runkle