From: Fay John F Dr CTR USAF AFSEO/SK <John.Fay.ctr@Eglin.af.mil> - 2007-03-22 21:08:56
I went and looked at the SVN repository and I don't see anything
that has changed in the last three months. I looked in the source code
and found ...
- The messages about direct rendering contexts are found
in "freeglut_window.c" around line 534. The code has just called
"glXCreateContext" with the last argument true unless the application
specifies an indirect rendering context and then calls "glXIsDirect".
- The event loop handling is done in "glutMainLoop",
which is in "freeglut_main.c" starting around line 1440. Within the
loop, the function calls "glutMainLoopEvent" (line 1475) and then calls
the idle callback if one exists.
I think the most proper solution is for your application's idle
callback not to call "glutPostRedisplay". The "glutPostRedisplay"
function is supposed to be called after the rendering of graphics, and
that is supposed to be done in the display callback rather than the idle
callback. (I realize that pretty much ALL the GLUT demos render their
graphics in their idle callbacks, but this is not the way life should
I'm not sure what has caused the change in behavior.
John F. Fay
Jacobs Technology TEAS Group
[mailto:freeglut-bugs-bounces@...] On Behalf Of
Sent: Wednesday, March 21, 2007 5:06 PM
Subject: [Freeglut-bugs] glutSwapBuffers() somtimes ignored or
on our new Linux workstation (Suse 10.2) I detected a strange behavior=20
in my interactive OpenGL animations using glutIdelFunc().
I am redirecting the OpenGL output to my HP-UX workstation or to a PC=20
running ReflectionX as usual and now get several messages, that freeglut
can not create a *direct* connection, stating that this may reduce=20
performance. These messages do not occur in all my older freeglut
But in general the performance seems to be the same as before (hardware=20
accelerated), but it looks now as if the new freeglut version does not=20
wait for the glutSwapBuffers() function to finish and therefore calls my
glutIdelFunc much too rapidly (10 to 100 times more frequent than=20
before, resulting in up to 4000 calls/sec!). My Idelfunc recalculates=20
the (typically slowly rotating) view and calls glutPostRedisplay() which
leads to a call of my glutRedrawFunc that ends with a call to=20
This seems to fill up some display fifo with hundreds of updates! If the
user interacts, he has to wait several seconds for the buffer to drain=20
until his mouse motion events get visibly processed. The same=20
misbehavior seems to happen with very rapid mouse motions too, because=20
there is a noticeable inertness if the graphic is more complex.
All this does NOT occur if I execute my application on the older Linux=20
PC (Suse 10.0) or simply link it with my self made oldglut (glut.org=20
3.8). The same source compiles and runs fine under HP-UX 11.11 too -=20
without any inertness at all.
Has anyone (John Fay?) got an idea what is going wrong here?
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
opinions on IT & business topics through brief surveys-and earn cash
Freeglut-bugs mailing list