From 46f090da2c80d5c5e4cd8efc8a7344dd19fa20ef Mon Sep 17 00:00:00 2001 From: rkrolib Date: Sun, 1 Feb 2004 09:18:59 +0000 Subject: [PATCH] Close a bug whereby events can be delayed arbitrarily long if they get caught between the socket and the client-side queue on X, sometime after glutMainLoopEvent()'s loop quits and before the sleep code is invoked. git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@449 7f0cb862-5218-0410-a997-914c9d46530a --- freeglut/freeglut/src/freeglut_main.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/freeglut/freeglut/src/freeglut_main.c b/freeglut/freeglut/src/freeglut_main.c index 1806698..68c530c 100644 --- a/freeglut/freeglut/src/freeglut_main.c +++ b/freeglut/freeglut/src/freeglut_main.c @@ -452,6 +452,16 @@ static void fgSleepForEvents( void ) msec = MIN( msec, 10 ); /* XXX Dumb; forces granularity to .01sec */ #if TARGET_HOST_UNIX_X11 + /* + * Possibly due to aggressive use of XFlush() and friends, + * it is possible to have our socket drained but still have + * unprocessed events. (Or, this may just be normal with + * X, anyway?) We do non-trivial processing of X events + * after tham in event-reading loop, in any case, so we + * need to allow that we may have an empty socket but non- + * empty event queue. + */ + if( ! XPending( fgDisplay.Display ) ) { fd_set fdset; int err;