Re: Slow lablgl. (fwd)

Re: Slow lablgl. (fwd)

[peter_ronnquist]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]


Some good news, gears.ml now runs in the same speed division as gears.c. 
 Hardware acceleration works well and this even when I compile to byte code. 
Although to see the output done in the window I have to move the window 
once, this forces a redisplay I guess.

The mistake done on my part was that I missed that the 

Togl.timer_func ~ms:20 ~cb:(fun () -> view#idle);

function was set to 20 ms, so of course it did not get higher frame rates 
than 50 fps. 
I changed it to 5 ms and used a big window (about 800 * 600) and it performed 
similarly to the gears c version.
Needless to say I am quite impressed with this.

Now there is only one problem left, when I compile gears.ml to native then 
it takes a long time (maybe some minutes) with almost all processor time 
used and when I run the resulting executable the machine freezes. 
Do you get similar problems with gears.ml when compiling to native?
This is not so serious for me at the moment since the byte code compilation 
works alright for my intentions.

Best Regards 
Peter Rönnquist

Re: Slow lablgl. (fwd)

[Peter Ronnquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 416 bytes --]

Regarding the direct rendering and lablgl, the
libraries are the correct ones on the executable
produced when planet.ml is compiled to native. So the
problem must be in the example itself. I will try to
find it.

Best Regards 
Peter Rönnquist


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Slow lablgl. (fwd)

[peter_ronnquist]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

Hi,

Jacques, I think that you may know what the problem is with the slow lablgl 
(I hope you know).  My problem is that glxinfo says that I have direct rendering 
enabled and gears.c (not ocaml version) run really fast but the planet.ml 
and tennis.ml run slow. I suspect as Sven Luther suggest that it does not 
use the correct library for accelerated open gl.
I tried ldd on lablgl but it does not use dynamic libraries so maybe I must 
compile lablgl myself and link with some static accelrated library? Right 
know I don't know how to proceed.
I have installed ocaml, labgl from debian woody (no lablgtk+).

Thank you

Peter Rönnquist



---------- Forwarded message ----------
Date: Wed, 7 Feb 2001 18:13:05 +0100
Subject: Re: problems with compilation with lablgl.
From: Sven <luther@dpt-info.u-strasbg.fr>
To: peter_ronnquist@hushmail.com

On Wed, Feb 07, 2001 at 11:59:53AM +0000, peter_ronnquist@hushmail.com wrote:
> Hi, 
> 
> sorry for the late reply. I am using matrox G400 and athlon 700 mhz. I 
got 
> dri working, the gears.c (not the ocaml version) and that gives 900 fps 

lucky you, ...

I have a bi celeron box, and DRI freeze it solid some times, so no luck 
...

> in a small window.  The ocaml version of gears scrambles the screen and 
> I have to kill it from a console.

Don't know, it worked for me.

notice, if you use lablgtk+ lablgl, you will need to add doublebuffering 
to some examples, as they will not run without it.

> The planet.ml and tennis.ml runs slow though and I am trying to figuring 
> out why. Does these examples run accelerated for you? 

Like said, they have a tendency to freeze my box, so i disabled DRI. here 
on my home box, i have not yet finished writing DRI support for my permedia3 
based card.

But my guess is that you are not using the accelerated libraries.

What does glxinfo says to you ? 

Maybe there is a problem with the fact that ocaml is doing static linking,
 and not dynamic linking.

> I will investigate if not the planet.ml draws on in the "front" buffer 
and 
> not in the "back" buffer. I saw in some mailing list that it was much 
slower 
> if you did not use the "back" buffer.

Yes, using a back buffer should improve speed, but also improve fluidity 
of the display.

Hope this help, i think writing to jacques directly about this is more advised 
...

Friendly,

sven Luther