Version française
Home     About     Download     Resources     Contact us    
Browse thread
lablGL and the top-level
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques GARRIGUE <garrigue@k...>
Subject: Re: [Caml-list] lablGL and the top-level
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