From: Peter Ronnquist <peter.ronnquist@gmail.com>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.
Date: Tue, 26 Apr 2011 22:16:25 +0200 [thread overview]
Message-ID: <BANLkTikRZLex++KzZk3_GSe9V=uqWmXicw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTik8X_t_9xXq12iRRD-wNYY9Wwm2Lg@mail.gmail.com>
> Are you positive the language runtime system is the only
> change between your two setups ? For example, would a simple animation
> written in C and OCaml and F# perform differently ?
> It may also be an issue with the OpenGL FFI binding (I would trust the OCaml
> GC more than a hairy mix of OCaml/C code binding a large library).
I should add that the ocaml program is using sdl for setting up the
initial window and for syncing with the screen update.
When using C and sdl or using f# and opentk then the update of the
screen is completely smooth.
I'm comparing simple animations. For ocaml it is a moving rectangle,
in f# it is a rotating and zooming rectangle.
I have not thought about that it could be an issue with the OpenGL or
SDL binding although I still tend suspect that it is the GC/runtime
that interferes with the vertical blank synchronization.
Using glut (no sdl) and open gl gives a very visible "stuttering" both
with C and with ocaml but when using SDL and C then the result is
smooth animation.
My initial thinking was that it should be theoretically possible to
have smooth animation when using sdl and ocaml. When I tried it and
saw the occasional "stutters" my conclusion was that ocamls GC
interfere with the animation.
Then I tried f# and mono and realized that it is possible to have a GC
that does not interfere with the animation hence I began to experiment
with the GC configuration in ocaml without success.
Lastly I was thinking that it might be something else than the GC and
by the discussion here on the list and elsewhere it seems like the
unboxing management is one other difference between ocaml and f#/mono.
next prev parent reply other threads:[~2011-04-26 20:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-26 19:15 Peter Ronnquist
2011-04-26 19:30 ` Gabriel Scherer
2011-04-26 20:16 ` Peter Ronnquist [this message]
2011-04-26 19:39 ` Török Edwin
2011-04-26 20:37 ` Anthony Tavener
2011-04-27 6:51 ` rixed
2011-04-27 10:02 ` Jon Harrop
2011-04-27 21:08 ` Peter Ronnquist
[not found] <fa.bAPY0rzAUUqrEHcCwn9toRc5oMo@ifi.uio.no>
2011-04-26 20:38 ` Ethan Burns
2011-05-01 14:24 Peter Ronnquist
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='BANLkTikRZLex++KzZk3_GSe9V=uqWmXicw@mail.gmail.com' \
--to=peter.ronnquist@gmail.com \
--cc=caml-list@inria.fr \
--cc=gabriel.scherer@gmail.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