I am new to programming with OpenGL. I have been able to do some of the examples with no real issues. I was wandering is there a way to draw graphics without using the mainloop. I am looking to do a program that will draw graphics but will not leave the loop running so that other parts of the program can run and remain in control. If this can be done can someone point me to an example that I can look at.
Thanks in advance,
Walt
what is the problem? my program uses the main loop (XtAppAddMainLoop) and when running, other programs can be in control / “highlighted” and opengl rendering still occurs.
It’s an issue of event-driven programming and user-interface responsiveness. The event-driven model doesn’t look natural at first glance. But it makes sense for a lot of reasons.
Also, the main loop doesn’t actually do anything unless there are events to process (e.g. display, resize, etc.).
You can register callbacks to handle your application specific requirements (e.g. idle callback). You can also spawn other threads or processes.
Why are you wanting control over the main event loop?
I think that I might have been on a single track with this mainloop. I can work with this in the other aspects to my program. BTW i am writing a game with external devices that can effect the game outcome and display (message boxes, animation, numeric displays). I had already created a event loop and was worried about the interaction of the two loops (if any) and a solution was to just handle animation, resizing, etc… on my own by calling functions directly. I am not sure that this is the smart way to go…
Thanks,
Walt
What GUI toolkit are you using?
Make sure that your event loops cooperate nicely. Are they in the same thread? If so, make sure you don’t starve the GUI event processing. Otherwise your UI might appear non-responsive.
solution was to just handle animation, resizing, etc… on my own by calling functions directly.
Just FYI, it’s normally done the other way around – letting the GUI toolkit handle these events and designing the application to do it’s processing during the idle callback … or, alternatively, in another thread/process and updating the UI during the idle callback.
Right now I am using GLUT (freeglut actually). I have not had a chance to look at glx yet. Are there any that you would suggest?
I understand what you are saying about the process being reversed but I am use to using graphic libraries that make you do most of the work (older versions of SVGAlib). I do like the idea of not having to handle all of the details of the graphics processing. If all it takes is another process or thread then that would be the simple solution.
Thanks,
Walt
The usual thing to do with GLUT is to register callbacks for the events you care about (key, mouse, &c) and to register an idle callback which simply calls glutPostRedisplay. This will cause your display function to be called as often as possible in between processing the other events. I’ve never seen performance issues, and it’s not as complex as using a separate thread…
One reason you might need a thread is for time consuming tasks. In other words, don’t spend too much time in the idle callback. Otherwise, the UI will appear to lock-up. This is because the main-loop wouldn’t be able to effectually process queued events.
You can off-load expensive tasks to other threads (or use a more complex approach by subdividing the tasks into smaller pieces … which would be handled a small piece at a time each time through the idle callback).
Concerning which GUI toolkit to use … it depends upon your needs. I’d start with GLUT … until you need something beyond it’s capabilities. At least by then you’ll be comfortable with the event-driven approach 
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.