Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Example slowing down... (OpenGL/lablgl)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-04-12 (14:33)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] Example slowing down... (OpenGL/lablgl)
On Thu, Apr 12, 2007 at 08:15:24AM +0100, Jon Harrop wrote:
> On Wednesday 11 April 2007 23:25, Oliver Bandel wrote:
> >
> >
> > =================================================================
> >  let _ =
> >     ignore( Glut.init Sys.argv );
> >     Glut.initDisplayMode ~double_buffer:true ();
> >     ignore (Glut.createWindow ~title:"OpenGL Demo");
> >     let render () =
> >       GlClear.clear [ `color ];
> >       GlMat.rotate ~angle:(Sys.time() *. 0.01) ~z:1. ();
> >       GlDraw.begins `triangles;
> >       List.iter GlDraw.vertex2 [-1., -1.; 0., 1.; 1., -1.];
> >       GlDraw.ends ();
> >       Glut.swapBuffers () in
> >     Glut.displayFunc ~cb:render;
> >     Glut.idleFunc ~cb:(Some Glut.postRedisplay);
> >     Glut.mainLoop ()
> > =================================================================
> You'll notice the uncanny resemblance of that code to the code from OCaml for 
> Scientists:

There I get an error messaage that glutCreateWindow is called before

> > Or is the OCaml-code in the above example
> > written in bad OpenGl-style?
> Yes. I should not have used Sys.time() in the Wikipedia example because it 
> measures CPU time. Thus, as the program takes longer to run (e.g. in a larger 
> window) the rate of spinning will be affected. So you cannot infer the 
> graphics performance from the rate of spinning.

I have not looked at the examle in detail,
but if it's not an OCaml-problem then that's fine.
So I can switch my OpenGL-based programming to
Ocaml and can put my C-sources into my museum of Sorce code :)

> Instead, you must add a time 
> to count how many frames of animation are displayed each second.

It's too long ago, when I thought about theese timing issues, but
as far as I know that is not to much a problem.
The Redbook is for C-language but explains the detail very good,
so if it's an OpenGL-programming problem, this can be fixed.
It would be bad if it would be an OCaml-problem, becaue I then
would have to mix C- and OCaml-code; and if possible I prever
pure OCaml-code.

As far as I know the idle-task can be used for timing-things;
but I have to re-read the redbook (or my C-code) to be sure.

> This may be the problem. However, I'd be surprised if that makes a visible 
> difference because your machine should be easily capable of spinning a 
> triangle using only software rendering.

Maybe one could think this.
But it's a single core machine and if a lot goes on there,
something slows down.
A accelerated graphics driver accelerates the rendering stuff,
but if the commands that invoke these commands are not comming
fast enough, no acceleration could help.
And if the machine makes many things at the same time...

It's good to let the graphics card do the work, instead
to make too much with the CPU, what the graphics card
could do. Then it slow's down and the graphics renderer is bored.

BTW: the machine Is amazingly fast compared to my five/six years
old Powerbook (slow disk also), but full-screen means 19'' and it's
not fastest machine around.  It was the cheapest ;-)

About 4054 bogomips (whatever that means ;-) .. it's bogo ;-))
and the CPU runs on 2 GHz, even if the board could be used faster.
It's not a highend-machine, but for me it's a step forward and fine.