Example slowing down... (OpenGL/lablgl)

Example slowing down... (OpenGL/lablgl)

[Oliver Bandel]

Hello,

today I tried lablgl the first time succesful. :)

It's nice.

I tried the example from

  http://en.wikipedia.org/wiki/OCaml

=================================================================
 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 ()
=================================================================

That's nice, only 14 lines of code and the example is done. :)

But after I made the window with the triangle greater,
this examplke slowed down extremely! :(

It seems that it does not use the features of the
graphics card for some reasons. (??!)

I have a gentoo-linux and an nvidia graphics card in the
PC. Running on AMD-64 architecture.

The first days I didn't used the closed-source nvidia drivers and tried
an old C-source I had written. It was a threded application;
in one of the thredas I had temporarily inserted one of the OpenGL-examples
from the RedBook. This was intended as aa placeholder for some time,
until I would write my own OpenGL-stuff for that thread.

In a small window that RedBook-example was amazingly fast.
And it slowed down, when making the window bigger, but nevertheless
was fast enough. When using "fog" effects, it slowed down extremely.

Later I used the nvidia-driver and it was so amazingly much more faster
than before, and slowing down, when making the window greater, was
not such a big effect. Using fog nearly had no effect.

The sources of the RedBook-example are written in C.


And today I tried OCaml with lablgl and this simple
triangle.
In a small window it was circling very fast, but making the window
bigger slowed down the circular velocity a lot!

What's going on here?
Is the lablgl-binding - for some reason - NOT
using features that are using accelerated graphic-card's
features? Is the binding relaying on non-accelerated
functions?

Or is the OCaml-code in the above example
written in bad OpenGl-style?
(But I see the keyword double-buffering in the example,
 so it should be fast (?!))

Or is OCaml itself slowing down for some reasons?

As I didn't have changed the X11-settings (using X11-Xorg-Server)
the same (accellerated) driver is running as it was as I tried the
RedBook-examples.

So there must be something with the above code or the lablgl-Lib
or with OCaml that makes the application slowing down, when the
window is enlarged.


Someone who knows, what the problem is?!

Thanks In Advance,
      Oliver Bandel

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[skaller]

On Thu, 2007-04-12 at 00:25 +0200, Oliver Bandel wrote:

> So there must be something with the above code or the lablgl-Lib
> or with OCaml that makes the application slowing down, when the
> window is enlarged.
> 
> 
> Someone who knows, what the problem is?!

You're not running the proprietary nVidia driver.

http://gentoo-wiki.com/HOWTO_nVidia_Drivers

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Oliver Bandel]

On Thu, Apr 12, 2007 at 10:07:11AM +1000, skaller wrote:
> On Thu, 2007-04-12 at 00:25 +0200, Oliver Bandel wrote:
> 
> > So there must be something with the above code or the lablgl-Lib
> > or with OCaml that makes the application slowing down, when the
> > window is enlarged.
> > 
> > 
> > Someone who knows, what the problem is?!
> 
> You're not running the proprietary nVidia driver.
> 
[...]

I am running the nvidia driver.
Definitely!

Ciao,
   Oliver

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Jon Harrop]

On Wednesday 11 April 2007 23:25, Oliver Bandel wrote:
>   http://en.wikipedia.org/wiki/OCaml
>
> =================================================================
>  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:

  http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation/

> 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. Instead, you must add a time 
to count how many frames of animation are displayed each second.

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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Oliver Bandel]

On Thu, Apr 12, 2007 at 08:15:24AM +0100, Jon Harrop wrote:
> On Wednesday 11 April 2007 23:25, Oliver Bandel wrote:
> >   http://en.wikipedia.org/wiki/OCaml
> >
> > =================================================================
> >  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:
> 
>   http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation/
> 

There I get an error messaage that glutCreateWindow is called before
glutInit.


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

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

Ciao,
   Oliver

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Jon Harrop]

On Thursday 12 April 2007 15:33, Oliver Bandel wrote:
> > http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation/
>
> There I get an error messaage that glutCreateWindow is called before
> glutInit.

Ugh, sorry. They changed freeglut to be more pedantic (which might actually 
fix some crashing issues I had with Presenta). You need to call glut.init as 
the Wikipedia example does.

> I have not looked at the examle in detail,
> but if it's not an OCaml-problem then that's fine.

Well, I think it is probably just the choice of "time" function. Try it to 
make sure though.

> So I can switch my OpenGL-based programming to
> Ocaml and can put my C-sources into my museum of Sorce code :)

Most people use sourceforge. ;-)

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

I doubt you will need to. There is very little that will run faster in C these 
days.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Martin Jambon]

On Thu, 12 Apr 2007, Jon Harrop wrote:

> On Thursday 12 April 2007 15:33, Oliver Bandel wrote:
> > > http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation/
> >
> > There I get an error messaage that glutCreateWindow is called before
> > glutInit.
>
> Ugh, sorry. They changed freeglut to be more pedantic (which might actually
> fix some crashing issues I had with Presenta). You need to call glut.init as
> the Wikipedia example does.
>
> > I have not looked at the examle in detail,
> > but if it's not an OCaml-problem then that's fine.
>
> Well, I think it is probably just the choice of "time" function. Try it to
> make sure though.

No, it seems to be related to the matrix accumulating numerical errors.
The following works just fine:

let _ =
  ignore( Glut.init Sys.argv );
  Glut.initDisplayMode ~double_buffer:true ();
  ignore (Glut.createWindow ~title:"OpenGL Demo");
  let angle t = 10. *. t *. t in
  let render () =
    GlClear.clear [ `color ];
    GlMat.load_identity ();
    GlMat.rotate ~angle: (angle (Sys.time ())) ~z:1. ();
    GlDraw.begins `triangles;
    List.iter GlDraw.vertex2 [-1., -1.; 0., 1.; 1., -1.];
    GlDraw.ends ();
    Glut.swapBuffers () in
  GlMat.mode `modelview;
  Glut.displayFunc ~cb:render;
  Glut.idleFunc ~cb:(Some Glut.postRedisplay);
  Glut.mainLoop ()




--
Martin Jambon
http://martin.jambon.free.fr

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Jon Harrop]

On Thursday 12 April 2007 21:26, Martin wrote:
> No, it seems to be related to the matrix accumulating numerical errors.

No. It is the time function.

You can check the numerical error by computing the determinant, which remains 
accurate to 1 part in 10^5 after 3600 frames. The mean numerical error 
probably scales as sqrt n because the floats are "random".

> The following works just fine:
>
> let _ =
>   ignore( Glut.init Sys.argv );
>   Glut.initDisplayMode ~double_buffer:true ();
>   ignore (Glut.createWindow ~title:"OpenGL Demo");
>   let angle t = 10. *. t *. t in
>   let render () =

let a = GlMat.to_array(GlMat.get_matrix `modelview_matrix) in
let d = a.(0).(0)*.a.(1).(1) -. a.(1).(0)*.a.(0).(1) in
Printf.printf "%f\n" d;

>     GlClear.clear [ `color ];
>     GlMat.load_identity ();
>     GlMat.rotate ~angle: (angle (Sys.time ())) ~z:1. ();
>     GlDraw.begins `triangles;
>     List.iter GlDraw.vertex2 [-1., -1.; 0., 1.; 1., -1.];
>     GlDraw.ends ();
>     Glut.swapBuffers () in
>   GlMat.mode `modelview;
>   Glut.displayFunc ~cb:render;
>   Glut.idleFunc ~cb:(Some Glut.postRedisplay);
>   Glut.mainLoop ()

The original also works fine, depending what results you expect and whether 
you've forced vsync. If you want to check the latter, run nvidia-settings and 
select "OpenGL Settings".

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Martin Jambon]

On Thu, 12 Apr 2007, Jon Harrop wrote:

> On Thursday 12 April 2007 21:26, Martin wrote:
> > No, it seems to be related to the matrix accumulating numerical errors.
>
> No. It is the time function.
>
> You can check the numerical error by computing the determinant, which remains
> accurate to 1 part in 10^5 after 3600 frames. The mean numerical error
> probably scales as sqrt n because the floats are "random".

Actually it's just that the angle is not only a function of time, but also
of the period T between two frames:

  angle(t+T) = angle(t) + 0.01 * t

For example, if you interrupt the program and restart it a few seconds
later, the rotation will restart where it left (plus one tiny increment)
even though time is still running.


So there's probably no big trouble with the time function or the
rotation matrix.


Martin

--
Martin Jambon
http://martin.jambon.free.fr

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Jon Harrop]

On Friday 13 April 2007 01:30, you wrote:
> For example, if you interrupt the program and restart it a few seconds
> later, the rotation will restart where it left (plus one tiny increment)
> even though time is still running.

Yes. With vsync on the frame rate will be fixed though.

> So there's probably no big trouble with the time function or the
> rotation matrix.

You still shouldn't use Sys.time for animation because it measures CPU time 
and not real time.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[Oliver Bandel]

On Thu, Apr 12, 2007 at 08:46:18PM +0100, Jon Harrop wrote:
> On Thursday 12 April 2007 15:33, Oliver Bandel wrote:
> > > http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation/
> >
> > There I get an error messaage that glutCreateWindow is called before
> > glutInit.
> 
> Ugh, sorry. They changed freeglut to be more pedantic (which might actually 
> fix some crashing issues I had with Presenta). You need to call glut.init as 
> the Wikipedia example does.
> 
> > I have not looked at the examle in detail,
> > but if it's not an OCaml-problem then that's fine.
> 
> Well, I think it is probably just the choice of "time" function. Try it to 
> make sure though.

OK.
I will try my own attempts, and I think the
first ways will be paved twice: one thing in C,
the other in OCaml.

I hope that the names of the OCaml-functions will have very
similar names as the C-functions.

There is no seperated lablgl-documentation, right?!
So I have to look up for the C-API-functions and
guess the right names of the OCaml-pendants?!


> 
> > So I can switch my OpenGL-based programming to
> > Ocaml and can put my C-sources into my museum of Sorce code :)
> 
> Most people use sourceforge. ;-)
> 

...as a museum of old code? ;-)



> > 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.
> 
> I doubt you will need to. There is very little that will run faster in C these 
> days.

Really? :)

OK, but you can't insert Assembler-code in OCaml-code directly ;-)

Ciao,
   Oliver

Re: [Caml-list] Example slowing down... (OpenGL/lablgl)

[skaller]

On Thu, 2007-04-12 at 20:46 +0100, Jon Harrop wrote:

> I doubt you will need to. There is very little that will run faster in C these 
> days.

Calculating ackermann(3,y):

Rankings for ack on rosella, amd64x1 1G,ubuntu:

processor:            y   secs  samples, deviation
    felix            13   5.51 [N=  3 SD= 2%]
    gnat             13   9.59 [N=  1 SD= 0%]
    gccopt           13   9.84 [N=  2 SD= 0%]
    ocamlopt         13  13.76 [N=  3 SD= 0%]

    felix            12   1.23 [N= 10 SD= 0%]
    gccopt           12   2.37 [N=  6 SD= 0%]
    gnat             12   2.40 [N=  9 SD= 0%]
    ocamlopt         12   2.47 [N=  7 SD= 0%]

    felix            11   0.30 [N=  3 SD= 0%]
    gccopt           11   0.59 [N= 11 SD= 0%]

Lucky register allocation I guess .. :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net