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 (20:52)
From: Fabrice Marchant <fabrice.marchant@o...>
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?
> > >   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.
 Hi Oliver !

  I agree doing this call to 'synchronize' at this rate has absolutely
no meaning.
  The reason it appears here : because I removed the statements of
my hanging code one by one until it remains enough to stick

> 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.
  The first link was to another dummy code only intended to demonstrate
the encountered issue with 'wait_next_event' + threads.

  In fact the true application where the problem originally raised is :
Y. A. Game of Life.
(*** is a good test pattern.)

  The thread code locates in ten lines autoplay.ml.
Suppressing the loop delay will cause 'wait_next_event' (and me)
to be stuck : the aim was to run the game at full speed.

  I didn't found anything about a bug in 'wait_next_event' so I ask :
who could say what's wrong in a thread loop without this f*ckin delay ?