caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
To: jon@jdh30.plus.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] lablGL and the top-level
Date: Wed, 02 Mar 2005 17:48:03 +0900 (JST)	[thread overview]
Message-ID: <20050302.174803.68555775.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <200503020818.16207.jon@jdh30.plus.com>

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


  reply	other threads:[~2005-03-02  8:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-02  8:18 Jon Harrop
2005-03-02  8:48 ` Jacques GARRIGUE [this message]
2005-03-07 14:05 ` [Caml-list] " Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050302.174803.68555775.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=jon@jdh30.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).