Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Fabrice Marchant <fabrice.marchant@orange.fr>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?
Date: Mon, 12 Nov 2007 20:54:11 +0100	[thread overview]
Message-ID: <20071112205411.0d2d6dfc@localhost.localdomain> (raw)
In-Reply-To: <1194828182.4737a196e3582@webmail.in-berlin.de>

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

> 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 :
http://fabrice.marchant.free.fr/funLife/
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 ?

 Regards,

Fabrice


  reply	other threads:[~2007-11-12 20:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-10 22:01 Fabrice Marchant
2007-11-11 14:07 ` [Caml-list] " Fabrice Marchant
2007-11-11 16:48   ` Oliver Bandel
2007-11-11 18:35     ` Julien Moutinho
2007-11-11 20:13       ` Fabrice Marchant
2007-11-12  0:33       ` Oliver Bandel
2007-11-11 19:40     ` Fabrice Marchant
2007-11-12  0:43       ` Oliver Bandel
2007-11-12 19:54         ` Fabrice Marchant [this message]
2007-11-12 21:18           ` Oliver Bandel
2007-11-13  7:45             ` Fabrice Marchant
2007-11-13 10:14               ` Oliver Bandel
2007-11-13 20:10                 ` Fabrice Marchant
2007-11-14  0:33                   ` Oliver Bandel
2007-11-12  0:46       ` Oliver Bandel
2007-11-12  6:18       ` Oliver Bandel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071112205411.0d2d6dfc@localhost.localdomain \
    --to=fabrice.marchant@orange.fr \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox