Thats what I'm currently doing, and I can do that when I have one
window, or a fixed number of windows. Needing to create and destroy
windows complicates matters a lot.
In another case, I wanted to have a GUI window operated by the main
thread of a program (another simulation), and and have another window
controlled by a secondary thread that would render the results of some
heavy duty calculations as the results became available. For performance
reasons I needed to have each window controlled by a different thread. I
ended up scraping the GUI.
The standard way of doing that sort of thing is have a single "graphics"
thread that controls the one or many windows, and offload the heavy
calculations on different threads which signal the main thread to
redisplay. Again there's no need to have multiple threads control
I definitely could if portability was not a major concern. That would
be more suited when graphics is the main concern of the application,
which in my case, isn't.
Also if you could use multiple processes as someone else suggested.
I'm not trying to say that multithreaded GLUT is or should be the
number one priority, but considering the multiple cores modern
processors offer, I see it as the logical evolution of freeglut,
whether it happens today, in the next release, or in a few releases.
So yes, it is desirable to have multiple windows controlled by a single
process running multiple threads, even if the cases where this would be
done are limited.
I'm not saying it wouldn't be nice to have that option. But I don't see
the "need" for it, nor do I find it interesting enough. There are much
more common and important cases where you can't use GLUT at the moment
and you have to resort to write your own GLX code than multithreaded
GLUT context support in my opinion.
One grudge I have is not being able to order a glut redisplay from a
different thread without some sort of hack.
For instance a long-standing grudge of mine is that I can't integrate
the glut main loop processing into my own select() loop as I can't get
the underlying X socket without resorting to terrible hacks.
Here are a few other things I think could be improved:
How interesting or useful those features would be is not for me alone
to judge, but I put them forth as proposals for freeglut 2.8.0.
- glutFullScreenToggle() doesn't leave fullscreen mode on Windows.
- I can't fullscreen on a secondary monitor
- Trying to create windows from separate treads will segfault
rather than freeglut elegantly returning an error.