caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Anthony Tavener <anthony.tavener@gmail.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.
Date: Tue, 26 Apr 2011 14:37:43 -0600	[thread overview]
Message-ID: <BANLkTikXVxCttMOqK05yJ0moCgecFXGTAQ@mail.gmail.com> (raw)
In-Reply-To: <4DB71F64.7030501@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

The problem with tearing will be in the way OpenGL is being used. The code
and hardware involved in the display update is not OCaml (or F#) generated.
You're setting things up for each frame with OCaml -- the rendering is
handled by OpenGL. So, as Török suggests, verify whether you have vsync
enabled in your OCaml implementation... and that lablgl and whatever other
layers render abstraction support it... I use glcaml+sdlcaml, so I'm not
specifically familiar with your case.

While the GC will not be responsible for tearing in a GL app... you will
eventually have to play with the GC for a game. In particular, with a
typical game you have an update loop running at a high rate and possibly
spewing out garbage (temporary allocations) at an alarming rate. Part of
optimizing will be to try preventing unnecessary allocations (not so much
copying in every system on every frame).

I sometimes add a call for minor collection as part of my frame update if I
suspect stuttering (which doesn't tear, but causes inconsistent framerate).
If that helps then I try to find what system is using up so much memory and
can generally improve it. In the end, you'll probably need to tune the GC,
and maybe even hint for collections at more ideal times. Games and realtime
simulations aren't like most other programs, so the GC isn't likely to do
the right thing without some hints! :)


2011/4/26 Török Edwin <edwintorok@gmail.com>

> On 04/26/2011 10:15 PM, Peter Ronnquist wrote:
> > Hi all,
> >
> > I have been experimenting with f# and mono on debian linux and
> > compared it with ocaml.
> > I am interested in visual presentations for example games and in my
> > tests f# + mono + opentk was able to make completely smooth animations
> > using opengl (opentk) on debian 6.0 (squeeze).
> >
> > Ocaml + lablgl gives "stutters" in the animation within the period of
> > a couple of seconds. The animation runs smooth for a couple of seconds
> > and then the animation update is disturbed with the result that the
> > image is "teared". The tearing lasts only for a fraction of second but
> > is visible for a trained eye.
>
> Did you try to synchronize to VSYNC?
> Also which OpenGL drivers are you using, some older versions of the
> Intel drivers used to have quite significant tearing even with 2D
> animations/video.
>
> >
> > I suspected that the GC could be a cause for this and I tried to
> > manipulate the GC settings but I could not get a completely smooth
> > animation for a longer period of time.
> >
> > This is completely acceptable for many applications but for making a
> > game or for the meticulous graphical applicaton user it is not ideal.
> >
> > My thought is that maybe f#/mono unboxes more values than ocaml and in
> > this way the GC doesn't need to work as hard?
>
> Try 'latencytop', and 'perf record/perf report' to see where time is spent.
>
> >
> > My question really is if you think it is worthwhile to investigate the
> > runtime system for mono and compare it with the runtime system for
> > ocaml to locate the differences that might influence the animation and
> > then even update the ocaml runtime system to use a similar strategy
> > as the f# runtime system?
>
> Do you have a simple testcase? (OCaml code vs Mono code that easily
> reproduces the issue?)
>
> Best regards,
> --Edwin
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 4521 bytes --]

  reply	other threads:[~2011-04-26 20:38 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
2011-04-26 19:39 ` Török Edwin
2011-04-26 20:37   ` Anthony Tavener [this message]
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=BANLkTikXVxCttMOqK05yJ0moCgecFXGTAQ@mail.gmail.com \
    --to=anthony.tavener@gmail.com \
    --cc=caml-list@inria.fr \
    /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).