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! :)
On 04/26/2011 10:15 PM, Peter Ronnquist wrote:Did you try to synchronize to VSYNC?
> 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.
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.
Try 'latencytop', and 'perf record/perf report' to see where time is spent.
>
> 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?
Do you have a simple testcase? (OCaml code vs Mono code that easily
>
> 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?
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