Many thanks to Martin Cracauer and Madhu for their replies to my
original query.
Madhu puts his finger neatly on the crucial point in his comment (below)
on OpenGL.
In thinking about porting a large statistical project
(www.stats.uwaterloo.ca/Quail) to Linux,
it seemed useful to consider rewriting its graphics component to use
OpenGL which many speak
about very positively as a graphics standard.
Apologies if I have a wrong view on things in what follows.
I have a copy of the Redbook, which early on emphasises the description
in Madhu's note
below: once OpenGL's main loop is fired up, all the graphics stuff is,
as it were, off limits.
Thus, if I have it aright, the idea of 'interactive' which OpenGL
supports is encapsulated in the registered callbacks
established at the time the call to the main loop is made. These
callbacks take the form of, eg. mouse
events, including results from menus, keyboard events, including results
from dialogs.
All this exists in Quail now. However the graphics used by mcl/digitool
and allegro_cl do not take
charge of the main repl. So we are able to (1) run some analyses, (2)
note some interesting feature,
(3) use dialogs and menu options to explore further where those
explorations are 'registered',
(4) but if they are not, we can send instructions from the repl to the
views to show some additional stuff,
on the fly, in typical lisp interactions, without disturbing any of the
available graphics processing.
It is this last form of interaction which, as far as I can see, would
not be possible using OpenGL.
Thank you again for you patience in helping me understand things a
little better.
Let me display my ignorance of one piece of shorthand, what is an 'fd' as in
REPL fd ?
Cheers /Greg Bennett
Madhu wrote:
* Martin Cracauer <20090121162515.ga20...@cons.org> :
Wrote on Wed, 21 Jan 2009 11:25:15 -0500:
| You definitely want to do an event loop on the REPL fd and the
| graphics subsystem here, no threads.
|
| Whether it's easy to hack up cl-opengl to do that is a different
| matter but it would be wise on their part to provide a hook for an
| event loop.
|
| The threads in CMUCL won't work reliably as-is, green or not.
You're right of course, and my suggestion to use CMUCL:MP will not work
as expected. I apologise for posting that.
An example of how to do the event loop is in ltk.lisp (look for
SERVE-EVENT and comments there).
However this LTK approach has not worked reliably for me. Only CLX has
been satisfactory.
The problem with ALL foreign GUIs (GLUT, TCL, etc) is that they want
control of the main loop and it is is entirely in foreign land. The
application makes a foreign call to (say for example)
glutMainLoop(3GLUT)
,----
| enters the GLUT event processing loop. This routine should be called at
| most once in a GLUT program. Once called, this routine will never
| return. It will call as necessary any callbacks that have been
| registered.
`----
Once you hand over control to the foreign code, youre done. [If
somewhere the foreign code decides to call exit(2) your lisp process
dies]. Registering a callback to process events on other FDs may not be
always be feasible or reliable.
--
Madhu
