Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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