From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 449A6BC69 for ; Thu, 12 Apr 2007 16:33:34 +0200 (CEST) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l3CEXXG5002571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 16:33:34 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from first (dslb-088-073-066-231.pools.arcor-ip.net [88.73.66.231]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l3CEXWHA002020 for ; Thu, 12 Apr 2007 16:33:33 +0200 Received: by first (Postfix, from userid 501) id 5D3D93A6BC8; Thu, 12 Apr 2007 16:33:30 +0200 (CEST) Date: Thu, 12 Apr 2007 16:33:30 +0200 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Example slowing down... (OpenGL/lablgl) Message-ID: <20070412143329.GB396@first.in-berlin.de> References: <20070411222521.GA1603@first.in-berlin.de> <200704120815.24433.jon@ffconsultancy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704120815.24433.jon@ffconsultancy.com> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at discorde with ID 461E433D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 lablgl:01 0100,:01 bandel:01 wikipedia:01 wiki:01 ocaml:01 argv:01 buffer:01 triangles:01 iter:01 mainloop:01 ocaml:01 ocaml-code:01 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