lablGL and the top-level

lablGL and the top-level

[Jon Harrop]

It just occurred to me that the ability to run an interactive top-level to 
write and test OpenGL programs would be quite alluring. In particular, this 
would be a great way to introduce students to ocaml and graphics.

However, I'd like to use lablglut, which requires execution to be handed over 
to glut via a final call to glut.mainLoop. So, what would be the best way to 
get glut and the ocaml top-level to interoperate?

I guess you could write a glut idle function which provokes the top-level into 
asking for more input, but the display wouldn't be updated in the mean time.

Any ideas?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] lablGL and the top-level

[Jacques GARRIGUE]

From: Jon Harrop <jon@jdh30.plus.com>

> It just occurred to me that the ability to run an interactive top-level to 
> write and test OpenGL programs would be quite alluring. In particular, this 
> would be a great way to introduce students to ocaml and graphics.
> 
> However, I'd like to use lablglut, which requires execution to be handed over 
> to glut via a final call to glut.mainLoop. So, what would be the best way to 
> get glut and the ocaml top-level to interoperate?
> 
> I guess you could write a glut idle function which provokes the top-level into 
> asking for more input, but the display wouldn't be updated in the mean time.
> 
> Any ideas?

Threads are the natural way to do this.
This is already possible with GlGtk, using lablgtk -thread.
If you want to do this with glut, I see two possible approaches:
* Run the glut main loop in a different thread, and have it exit every
  100ms so you can yield and run the toplevel thread during this time
  (this is basically the way this is done in lablgtk)
  This is safe, but supposes there is an easy way to exit and reenter
  the main loop frequently.
* Release the ocaml mutex with caml_enter_blocking_section when
  entering the main loop. This of course means you must call
  caml_leave_blocking_section before calling any callback. Fortunately
  there are not too many ways to enter callbacks in glut. However,
  there is a further difficulty: you must avoid race conditions when
  making calls to openGL from the toplevel. The simplest way to do
  that is not doing calls directly, but putting them in a queue, and
  executing them in an idle callback from glut. Such an infrastructure
  is defined in gtkThread.ml (for windows users)
The first way is simpler on Unix (no races for free), but the Windows
GDI is such that you cannot call graphical functions from another
thread anyway, so you end up needing the queue. The second approach
feels cleaner, but is harder to program in.

      Jacques Garrigue

Re: [Caml-list] lablGL and the top-level

[Daniel Bünzli]

Jon,

Just in case you are not aware your problem is easy to solve if you use 
sdl [1] instead of glut to setup your gl context and handle input. Sdl 
doesn't own your main loop, you can poll or wait for events and then 
continue with your own code.

This simplifies a lot the interaction with the toplevel. For example, 
you can enter a function from the toplevel which will handle user input 
until the user presses escape to return to the toplevel and reenter the 
function later again. Or you can just initialize the context and then 
paint your window from the toplevel without handling the input in the 
window.

The features you loose with respect to glut is menus and multiple 
windows. But with sdl you don't need threads to solve your problem, you 
control the loop and this may be simpler for students (unless you want 
to introduce them to concurrency at the same time...).


A more brittle path to follow (with glut or whatever) which I did not 
investigate deeply is to use the (hidden) Toploop module and to try to 
render and control the toplevel in one of your glut window. However I 
don't know enough about Toploop to be sure you can get to the expected 
result.

Daniel

[1] <http://ocamlsdl.sourceforge.net/>