RATE experiment...
[1/20] from: cyphre::volny::cz at: 29-Aug-2001 16:16
Hi List,
I have been experimenting with 'rate parameter of face and found some
strange behaviour...
Try to run folowing code:
-----------snip--------------
view layout [
b: box blue with [
feel: make feel [
rate: 30
engage: func [f a e][
either not tog/state [
if e/type = 'time [
i: i + 1
if s < now/time [s: now/time f/text: reform ["rate: " i " fps"] show f
i: 0]
]
][
i: i + 1
if s < now/time [s: now/time f/text: reform ["rate: " i " fps"] show f
i: 0]
]
]
]
]
across
vtext "rate set to: "
r: vtext 30x20 "0"
return
sl: slider 100x16 [r/text: to-string b/rate: (to-integer face/data * 40) s:
now/time i: 0 show [r b]]
return
tog: toggle 200x20 "now tracking only time events" "now tracking all
events"
]
------------snip------------------
leave it in "tracking only time events" mode and try to set bottom slider to
different positions and watch what is blue box showing. I've tested under
WIN98 on [Celeron--530Mhz] and found that I cannot get over approx 20fps which
is IMO a little bit slow for such simple operation as showing simple text
face. Also when I set rate between 10-17 the real face refresh was still
around 9-10fps...strange??(but maybe my rate-meter code is not so much
exact...)
Now try to toggle to "tracking all events" mode and try to "drag-like" blue
face and keep moving over with pressed LMB. You will notice huge increasing
the rate (up to 60fps on my machine)....it seems like 'show is called with
every event going thru the face. I'm just wondering why I cannot go over
20fps with time events tracking only even it seems like I hve enough "power"
to achieve 60fps in the second mode?
I would appreciate nay comments, explanations or another experience on
different configurations/systems...
regards,
Cyphre
[2/20] from: dockimbel:free at: 29-Aug-2001 16:44
Hi Cyphre,
Richard Smolak wrote:
[...]
> leave it in "tracking only time events" mode and try to set bottom slider to
> different positions and watch what is blue box showing. I've tested under
<<quoted lines omitted: 3>>
> around 9-10fps...strange??(but maybe my rate-meter code is not so much
> exact...)
[...]
IMO, Rebol use the basic Dos (and Windows) timer which gives 18 ticks/sec. So
if you rely only on 'rate, you cannot fire more than 18 events/sec ! It would be
instructive to test your script on other OS with a fast processor.
Regards,
DocKimbel.
[3/20] from: cyphre:volny:cz at: 29-Aug-2001 17:54
Hi Nenad,
I've just tried it on G3 Mac at 233Mhz in my work and the behaviour is the
same like on [Celeorn--533Mhz] !!! I couldnot get over 20fpshere too.
It is very bad that we probably cannot get over 20fps using 'rate even on
strong enough machine :(( Maybe it is a bug or limitation of timing in
Rebol??
How can I make animation with 30 and more fps??? Maybe someone(probably
Holger) from RT should explain/comment this issue.
regards,
Cyphre
[4/20] from: holger:rebol at: 29-Aug-2001 9:36
On Wed, Aug 29, 2001 at 05:54:37PM +0200, Richard Smolak wrote:
> Hi Nenad,
> I've just tried it on G3 Mac at 233Mhz in my work and the behaviour is the
<<quoted lines omitted: 4>>
> How can I make animation with 30 and more fps??? Maybe someone(probably
> Holger) from RT should explain/comment this issue.
At the moment you cannot. It is a timer granularity issue. There is a good
chance though that we will change the implementation in a future version
to allow much higher granularities.
--
Holger Kruse
[holger--rebol--com]
[5/20] from: pwoodward:cncdsl at: 29-Aug-2001 12:34
Rich,
interesting - I'm managing 25 - 31 fps in the tracking time events only, and
I'm on a heavily loaded laptop with an 800MHz Pentium III (It's running a
Java App Server for development under Win2K, so a lot of resources are
consumed. I'll probably re-run things w/o the app server to see how things
go..). I get a huge boost when I switch over to tracking all events - up to
around 176 fps (I'm using one of those new-fangled laser USB mice, so the
sample rate on it is pretty high - along with CPU usage non-REBOL related,
when I move the mouse around alot, the CPU meter generally shows a 5%
usage).
I suspect that when idle REBOL is trying not to consume too many cycles -
why waste CPU cycles when sitting at a static display? But you're probably
more interested in doing something with animation, so you might like to try
for 30fps...
- Porter
----- Original Message -----
From: "Richard Smolak" <[cyphre--volny--cz]>
---SNIP---
[6/20] from: greggirwin:starband at: 29-Aug-2001 11:02
Hi Cyphre,
<< It is very bad that we probably cannot get over 20fps using 'rate even
on
strong enough machine :(( Maybe it is a bug or limitation of timing in
Rebol?? How can I make animation with 30 and more fps??? >>
I think it's probably a limitation of the underlying OS. Most animation runs
in the equivalent of a forever loop which is what makes its performance
bound by processor speed.
--Gregg
[7/20] from: cyphre:volny:cz at: 29-Aug-2001 19:01
Hi Holger,
That explains some of meanings about speed of /View engine ;-). What a
pitty!Gfx is slowed-down by rate timer :(((. I believe you will enhance the
scale of timer at least for 0.001seconds so we will be able to get from the
/View the best speed. This feature should be between top ten of your /View
enhancement list....without this feature we could forget multimedia projects
such a games, etc. running at brillant frame-rate speed...
regards,
Cyphre
[8/20] from: cyphre:volny:cz at: 30-Aug-2001 9:39
Hi Porter,
Thanks for your info...
> interesting - I'm managing 25 - 31 fps in the tracking time events only,
and
> I'm on a heavily loaded laptop with an 800MHz Pentium III (It's running a
> Java App Server for development under Win2K, so a lot of resources are
> consumed. I'll probably re-run things w/o the app server to see how
things
> go..). I get a huge boost when I switch over to tracking all events - up
to
> around 176 fps (I'm using one of those new-fangled laser USB mice, so the
Wow 176fps! Now you can see how fast could be Rebol gfx refresh without this
timer limitation
.
> sample rate on it is pretty high - along with CPU usage non-REBOL related,
> when I move the mouse around alot, the CPU meter generally shows a 5%
> usage).
>
> I suspect that when idle REBOL is trying not to consume too many cycles -
> why waste CPU cycles when sitting at a static display?
You are right, but 'rate parameter is used for forcing the refresh rate so
why it is so limited??
It's clear that you don't need it when refreshing i.e. some text status etc.
but higher framerate is a MUST for any real multimedia application.(And
remember Carl's speech that his second name is "Multimedia" ;-) )
Anyway, we are able to automaticaly lower rate when any /View window is
deactivated so don't be afraid of consuming CPU time when switching to
another application ;-).
> But you're probably
> more interested in doing something with animation, so you might like to
try
> for 30fps...
Yes, I started to develop cool gfx demo to show /View capabilities (and also
bugs and missing features) but after a few hours I hit this silly 'rate
barier :( I just wonder that noone noticed this limitation long time
before...) so everything will be running on boring 20 myabe 30fps on
high-end machines.
Once again thanks for your comment...
regards,
Cyphre
[9/20] from: cyphre:volny:cz at: 30-Aug-2001 9:46
Hi Gregg,
> I think it's probably a limitation of the underlying OS. Most animation
runs
> in the equivalent of a forever loop which is what makes its performance
> bound by processor speed.
>
I'm not WIN api expert but if /View behaves on Mac with the same limtation
it should be a problem of Rebol/View itself, not OS.
Furthemore, how can I explain myself that in "tracking all events" mode I'm
able to achieve many times higher rates??
Cyphre
[10/20] from: deadzaphod:flyingparty at: 30-Aug-2001 0:54
I had noticed this problem too, but had not followed up with tests to figure
out details, so I hadn't mentioned it to anyone. One thing I noticed was
that if I clicked out of the view window (on Win98) and kept moving the
mouse, the 'rate events were faster and more consistant/smoother. I hope
that we get a new version of view that fixes this soon.
Cal Dixon
-><-
----- Original Message -----
From: "Richard Smolak" <[cyphre--volny--cz]>
To: <[rebol-list--rebol--com]>
Sent: Thursday, August 30, 2001 12:39 AM
Subject: [REBOL] Re: RATE experiment...
Hi Porter,
Thanks for your info...
> interesting - I'm managing 25 - 31 fps in the tracking time events only,
and
> I'm on a heavily loaded laptop with an 800MHz Pentium III (It's running a
> Java App Server for development under Win2K, so a lot of resources are
> consumed. I'll probably re-run things w/o the app server to see how
things
> go..). I get a huge boost when I switch over to tracking all events - up
to
> around 176 fps (I'm using one of those new-fangled laser USB mice, so the
Wow 176fps! Now you can see how fast could be Rebol gfx refresh without this
timer limitation
.
> sample rate on it is pretty high - along with CPU usage non-REBOL related,
> when I move the mouse around alot, the CPU meter generally shows a 5%
> usage).
>
> I suspect that when idle REBOL is trying not to consume too many cycles -
> why waste CPU cycles when sitting at a static display?
You are right, but 'rate parameter is used for forcing the refresh rate so
why it is so limited??
It's clear that you don't need it when refreshing i.e. some text status etc.
but higher framerate is a MUST for any real multimedia application.(And
remember Carl's speech that his second name is "Multimedia" ;-) )
Anyway, we are able to automaticaly lower rate when any /View window is
deactivated so don't be afraid of consuming CPU time when switching to
another application ;-).
> But you're probably
> more interested in doing something with animation, so you might like to
try
> for 30fps...
Yes, I started to develop cool gfx demo to show /View capabilities (and also
bugs and missing features) but after a few hours I hit this silly 'rate
barier :( I just wonder that noone noticed this limitation long time
before...) so everything will be running on boring 20 myabe 30fps on
high-end machines.
Once again thanks for your comment...
regards,
Cyphre
[11/20] from: g:santilli:tiscalinet:it at: 30-Aug-2001 10:55
Hello Richard!
On 30-Ago-01, you wrote:
RS> few hours I hit this silly 'rate barier :( I just wonder that
RS> noone noticed this limitation long time before...) so
It was noticed in earlier betas, and it was said that it was
mainly a limitation in Windows' timer (it worked ok on Linux IIRC).
If it behaves in the same way in any platform now, probably it is
because they preferred to slow down other platforms over finding a
workaround on Win (which is probably not a trivial issue).
Anyway, could you just use a forever loop with a short WAIT?
Windows seems to be able to handle only busy loops. <g>
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[12/20] from: g:santilli:tiscalinet:it at: 30-Aug-2001 10:58
Hello Richard!
On 30-Ago-01, you wrote:
RS> I'm not WIN api expert but if /View behaves on Mac with the
RS> same limtation it should be a problem of Rebol/View itself,
RS> not OS. Furthemore, how can I explain myself that in
RS> "tracking all events" mode I'm able to achieve many times
RS> higher rates??
As Holger said, is a timer granularity issue. I assume that they
had to somewhat adjust REBOL's granularity to the worst case (Win)
--- but I might be totally wrong here.
Of course other events are not limited by the timer.
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[13/20] from: petr:krenzelok:trz:cz at: 30-Aug-2001 11:27
Gabriele Santilli wrote:
> Hello Richard!
> On 30-Ago-01, you wrote:
<<quoted lines omitted: 6>>
> had to somewhat adjust REBOL's granularity to the worst case (Win)
> --- but I might be totally wrong here.
Damn with crappy Windoze then! ;-) If it doesn't affect Rebol's
multiplatform functionality, why to be Windows dependant? Will we switch
to 2fps because PalmOS doesn't provides us with higher rates? :-)
I am not sure, but I remember Dave Haynie talking about own kernel for
Scala, because of lame Windows timers or so, so if Carl promised us with
Rebol/Scala, they will have to do something with it anyway ....
Cheers,
-pekr-
[14/20] from: greggirwin:starband at: 30-Aug-2001 10:04
Hi Cyphre,
OK, I just tested on my machine (P900, Win2K) and setting the slider to max
(40), I get 25 fps in all cases, setting it to min (0), I get 50 fps.
<< I'm not WIN api expert but if /View behaves on Mac with the same
limtation
it should be a problem of Rebol/View itself, not OS. >>
I don't know anything about MacOS to know if it might have the same issue,
or if REBOL's implementation is similar for both.
<< Furthemore, how can I explain myself that in "tracking all events" mode
I'm
able to achieve many times higher rates?? >>
It's possible that they have an internal message pump that feeds things
through when tracking all events. If that's so then they could be firing off
events as Windows messages come in, rather than waiting on a callback from
the Windows Timer they've created. Just a guess though. I'm still in the
crawling stage with REBOL so I don't have any idea how the feel stuff might
work.
--Gregg
[15/20] from: holger:rebol at: 30-Aug-2001 9:40
On Thu, Aug 30, 2001 at 09:46:19AM +0200, Richard Smolak wrote:
> I'm not WIN api expert but if /View behaves on Mac with the same limtation
> it should be a problem of Rebol/View itself, not OS.
> Furthemore, how can I explain myself that in "tracking all events" mode I'm
> able to achieve many times higher rates??
Timer events are different from some other events, such as mouse movement.
Don't worry about the rate cap for now. If/when REBOL moves more forcefully
into the multimedia markets, the timer subsystem will obviously be upgraded.
--
Holger Kruse
[holger--rebol--com]
[16/20] from: cyphre:volny:cz at: 30-Aug-2001 20:35
> Don't worry about the rate cap for now. If/when REBOL moves more
forcefully
> into the multimedia markets, the timer subsystem will obviously be
upgraded.
Holger, REBOL cannot forcefully move into multimedia markets without such
basic things. Imagine...I made some multimedia-like demo for possible
customer and tell him during the presetation "This animation couldnot run
better than 20fps or so...maybe when we play it on 1GHz pentium maybe we
would achieve 30fps..."
It is like making incomplete car and saying "If this car win 'The car of the
year' prize we will put into next model motor."
I know that graphic is just one piece of Rebol products...I just always
thought from Carl's words that RT wants to make something better than "yet
another another compositing system"....or maybe my POV is a little bit
distorted.
Cyphre
[17/20] from: petr:krenzelok:trz:cz at: 30-Aug-2001 20:58
----- Original Message -----
From: "Holger Kruse" <[holger--rebol--com]>
To: <[rebol-list--rebol--com]>
Sent: Thursday, August 30, 2001 6:40 PM
Subject: [REBOL] Re: RATE experiment...
> On Thu, Aug 30, 2001 at 09:46:19AM +0200, Richard Smolak wrote:
> > I'm not WIN api expert but if /View behaves on Mac with the same
limtation
> > it should be a problem of Rebol/View itself, not OS.
> > Furthemore, how can I explain myself that in "tracking all events" mode
I'm
> > able to achieve many times higher rates??
>
> Timer events are different from some other events, such as mouse movement.
>
> Don't worry about the rate cap for now. If/when REBOL moves more
forcefully
> into the multimedia markets, the timer subsystem will obviously be
upgraded.
multimedia market - even yesterday was late :-)
-pekr-
[18/20] from: fsievert:uos at: 31-Aug-2001 9:58
At least with Linux, this works:
; Patch the do-events - Function:
timer: none
do-events: func [/local s tmp] [
s: 0
forever [
tmp: now/time/precise
wait 1 / 30 - s
s: (to-decimal tmp) + (1 / 30)
do timer
if empty? system/view/screen-face/pane [break]
s: (to-decimal now/time/precise) - s
]]
; Now "timer" will be called up to every 1 / 30 second:
use [c s] [
timer: [
box/color: complement box/color
show box
if none? s [
c: 0 s: now/time/precise
]
if s + 0:0:5 < now/time/precise [print c / 5 s: none]
c: c + 1
] s: none
]
view layout [box: box red]
On Thu, 30 Aug 2001, Petr Krenzelok wrote:
[19/20] from: cyphre:volny:cz at: 31-Aug-2001 10:49
Hi Frank,
I've tried it under WIN98 on 533Mhz Celeron and got 18.5 fps...also when I
move mouse over the face it changes to about 23-4fps. It seems we couldnot
patch easily such problem from script layer.
Timer as a basic element of any event system has to be fixed natively.
Regards,
Cyphre
[20/20] from: fsievert:uos at: 31-Aug-2001 11:56
[wait 0,xy] is more precise with linux than the 'rate facet. So you can
fix it here. For windows it is not, as it seems. :(
CU,
Frank
On Fri, 31 Aug 2001, Richard Smolak wrote:
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted