English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Why 'Graphics.wait_next_event' doesn't reply anymore ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-11-12 (00:43)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?
Hi Fabrice,

sorry, have not much time to answer, I think it's time to sleep ;-)

But a short one...

Zitat von Fabrice Marchant <fabrice.marchant@orange.fr>:

>   Hi Oliver !
>  Thanks to have considered my problem.
> On Sun, 11 Nov 2007 17:48:34 +0100
> Oliver Bandel <oliver@first.in-berlin.de> wrote:

> >   let code1 () =
> >         let x = ref 0 in
> >         while true do
> >           incr x;
> >           Printf.printf "alpha %d\n" !x;
> >           flush stdout
> (*                      ;
>             display_mode false;
>             fill_circle 100 100 20;
>             synchronize ()*)
> >         done

Why do you want to call synchronize that often?

I didn't tested your code, so I don't know what's going wrong.
But calling synchronize that often IMHO makes no sense.
It's similar to calling Thread.yield to often.

For an average eye/viewer, it would be enough to call
synchronize all 1/25 seconds.
So, a thread that makes the timing and then calls
synchronize would be the right way, IMHO.
Or if you need higher frame rates, call it more often.
But I doubt in today machines, putting it inside a loop as you did,
would make sense.
And it also will waste ressources. It's not needed that fast,
because the eye is not fast enough.
So, there is no reason to call that function so often.

BTW: What's about your code, you sent?
Did you throw it away, or do you want some help there?
It looked to big for spare time, but maybe the next days
I can look on it. But possibly, if the toto.ml
(the code on which I already answered) is OK for you,
I would ignore your first code.


P.S.: Good night ;-)