Hi Sven, hi John,
thanks for the reply of both of you!
At first I can say that I already added a glFinish() behind the
glutSwapBuffers() on my own yesterday and *everything concerning the
inertness works well again*, like in the last 6 years we are living with
my occasionally animation done via the glutIdelFunc().
I am only sometimes animating the rotation of the viewpoint, if the user
wants it by prodding the object, nothing else. I don't know how to deal
with the glutTimerFunc() while I leave the glutMainLoop() for other very
long lasting (several hours) calculations, or for the real computed
animation that makes a complete redraw of the changed parts in the
"world" (in realtime, many per second).
The annoying inertness in the motion callback *was* noticeable even
without any animation or idelfunc, just caused by the huge amount of
glutPostRedisplays done after handling each of these events
asynchronously. So I think it is better to block after redraw and wait
-coalescing the events- rather than proceeding and producing much "type
ahead".
I do not understand John: How should things get visible, if I only
change some variables and the point of view in the idelfunc without
requesting a redraw by posting a redisplay? Really everything is stored
in displaylists, so it is not a hard work for OpenGL (only for the
graphics card).
AND
I do not call "glXIsDirect()" or specify anything as being "direct" or
"indirect" so far. The connection is almost always indirect by now,
because most of the users sit in front of their own Windows PC running
the Linux application in ReflectionX.
*So, how can I avoid all these about 100 warning messages I get in this
new release at startup (one for every window and one for every menu in
each window)?*
Cheers,
Hanno
> On Wednesday 21 March 2007 23:05, Johannes Falk wrote:
>
>> [...] Has anyone (John Fay?) got an idea what is going wrong here?
>>
>
> I don't think that anything is going wrong:
>
> http://www.opengl.org/resources/libraries/glut/spec3/node21.html
>
> glutSwapBuffers() does an implicit glFlush(), not a glFinish(), i.e. it
> doesn't wait for the completion of queued rendering commands. If it does
> under special circumstances, this is just by luck because of the
underlying
> OpenGL/GLX implementation.
>
> In general, I think that glutIdleFunc() is not a very good idea for
> interactive programs, glutTimerFunc() is often much more appropriate
IMHO.
>
> Cheers,
> S.
>
=============================================================================00
> 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
> be.)
>
> I'm not sure what has caused the change in behavior.
>
> John F. Fay
>
|