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
>
>