World: r3wp

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

That's excellent Richard! Heavy on the CPU, but still...

cool to see, what even non-HW accelerated View can do.

(found a way to have time events)

Gregg, hmm...just checked the CPU usage and it looks like some regression 
in R3 view timers to me.
in R3 (2.100.97.3.1):
forever [wait 0:00:00.1] eats 10% of CPU 
forever [wait 0:00:00.01] eats 100% of CPU 

while both tests in R2 eats nothing.

Cyphre - are you sure?

IIRC, there are two modes for the timers, depending upon needed granularity. 
You measure two different times ...

http://www.rebol.net/r3blogs/0293.html

Plus, those mltimedia timers that people keep talking about use more 
CPU.

as for Windows, we know which timers are best, right? IIRC those 
were queue timers, but Carl said, that R3 timers are already OK

Pekr, not sure what you mean by two modes. I believe in Windows R3 
is using one method using the high-resolution timer using QueryPerformanceFrequency() 
-  http://msdn.microsoft.com/en-us/library/ms644905%28VS.85%29.aspx
Which should be more precise than R2 and it looks it  works OK.


The problem I see is why the CPU should be at 100% when I'm forcing 
the loop WAIT for 10ms which is plenty of free time. Isn't it?

http://www.rebol.net/r3blogs/0088.html

A more accurate post on what's going on.

hmm, but this stil doesn't address my question no?

It says the resolution is one milisecond which is cool. So why wait 
10ms doesn't let  CPU idle enough so it is not at 100% of usage?

I'm with Richard on this.

I seem to recall that .002 was a lower limit that could cause issues 
in R2 if you went below that.

Yes, I'm not talking about precisison..this is not important in the 
tests above. The problem is why empty loop with enough IDLE time 
for CPU is making it at 100%

probably only Carl can answer this ...

Cyphre, I'm not sure if this is relevant, but timers under OSX are 
currently broken, so wait will eat CPU no matter what the wait period 
is. Maybe something broke in the last few versions?

I don't know about OSX, sorry. I refer to Win versions just to be 
clear.

Also I just tried to test under some prehistoric alpha prototype 
R3 versions and the 100% usage is there so I wonder noone noticed 
that so far :)

Right. It seems that it's overhead in WAIT.

Gregg, yes in R2 it looks the resolution that can be measured under 
Windows is ~10ms and you start to burn your CPU at 100% when you 
WAIT 0.0001 which means in R2 the same as WAIT 0.

Right. I thought maybe R3 had an artifact of that, but it doesn't 
seem so. CPU use goes up as you decrease the wait time, there doesn't 
seem to be a magic threshold.

Gregg, yes it looks like that...either there is some bug in WAIT 
or WAIT is not letting CPU to get IDLE state anymore from some reason.

Agreed.

The only possibly related thing I can find is http://curecode.org/rebol3/ticket.rsp?id=379&cursor=30

I think the OS_Wait() function in Host kit could give us some answer. 
I'll try to recompile with some debug info....

Is a simple LOOP with a WAIT in it enough for the bug report?

Ah, OK. That sounds good.

Are you Guys using wait , instead of time events in your GUI ?

yes,  the above discussion is wait command inside loop.
BTW what time events you mean?

like in R2 the time events generated by the rate propertie

AFAIK there is no RATE in R3. Or am I missing something?

there's no rate but you can generate time events aswell

not documented though

you mean like make event! [] right?

yep

but constructing an event is not enough, you have to know where to 
push it :)

ok, but even if you generate own events you need to WAIT at some 
point so the CPU is not at 100% no?

no, it depends of the duration of the process triggered by your events, 
if it takes too much time, it will froze the CPU obviously.

i have not made tests so far actually

just guessing

can you post any example if it is not too big?

i could, perhaps tomorrow, i have not the source at my home.

The principle is simple.

At startup, I build an event time!, the I push it in the block located 
at system/view/event-port/state.

And In my global event handler, each time I receive this event, I 
repush it immedialtly in the queue.

I receive 1000 time! events per seconds in My tests, but it mights 
depend of the speed of your UC

ok, no hurry...I'll also try to play with it later.

hmm, I pushed event into the event-port/state but nothing happened 
here. the event is still there and was not send to my global handler.

did you do a do-events ?

yes, tried both do-events or just calling VIEW