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
next prev parent 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