World: r3wp

Gabriele, that was my question too.  Currently If you have 'busy 
loop', no matter what technique you are using, you need to 'idle' 
at some point to give CPU some free time. Currently I don't know 
of a way how to do it in R3 as the CPU is getting high even on very 
long(in terms of CPU time) idle delays.

try this:

screen: system/view/screen-gob
event-port: system/view/event-port: open event://
event-queue: system/ports/system/state
push-event: func [event][append event-queue event]
push-event time-event: make event! [type: 'time port: event-port]
process-timers: does [
	push-event time-event
	forskip timers 2 [
		case [
			not integer? timers/1 []
			positive? timers/1 [timers/1: timers/1 - 1]
			zero? timers/1 [timers/1: do :timers/2]
		]
	]
]
event-port/awake: func [event][
	switch/default event/type [
		time [process-timers]
		close [halt]
	][
		print [event/type event/offset now/time/precise]
	]
]
timers: [
	1000 [print ["1000 ticks" now/time/precise] 1000]
	4500 [print ["4500 ticks" now/time/precise] 4500]
]
show append screen make gob! [
	offset: 50x50
	size: 100x100
	flags: [resize]
]
do-events

Ah, so you are inserting the events system port not event port. That 
was the difference.

I tried it here...works here in case the event loop doesn't contain 
any time consuming code(ie. is almost 'empty' as in your example).

But when I add some 'load'  into the loop then receiving of other 
event types is going to be rapidly limited/blocked when comparing 
to the FOREVER loop.

Either I'm doing something wrong or inserting events from the awake 
handler somehow blocks the whole flow.

cyphre, your system is similar to the R2 globs engine in spirit.

but since the data is stuff I create, I can't READ the data which 
is being managed by AGG.  which would be the major benefit of  "draw 
elements"

So let's have DRAW elements then, no? :-)

Cyphre - do you understand, what Max wants? And for us dumb - would 
it be a benefit, to have "draw elements"? :-)

Maxim, with this system you can easily manage any draw element or 
group of draw elements inside draw block.

I have been thinking about this and I don't see any benefit being 
able to access the data at the level of internal AGG structure. Rather 
it looks like it would make the whole system more complex.

The only thing which could be useful is being able to 'cache' already 
parsed DRAW block. That change can be done without much complications. 
But I should also mention that the 'parsing phase' is very little 
part of the performance overhead so cahing the internal structure 
would be theoretically useful only for really big DRAW blocks with 
tens of thousands and more elements..but such big blocks would be 
still not much usable becuase of the final performance of the rasterizing/rendering 
phase in such case.

But I'm still open and I'd like to know your clarification and explanation 
of the benefits you see in your requested feature though.

faster than light :-)

Steeve: what you are doing there is called a "busy loop".

AGG does a lot of computation, basically having access to this data 
in a consistent way.  also not having to use composed/reduced blocks 
all the time.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  

getting intersections between complex shapes like splines and polygons, 
xformed.
bounding boxes of things, calculated points of displayed letters.


if there where a unified method which just keeps the persistent data 
and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.

So you want kind of API access to low level AGG engine elements? 
Kind of like Extensions can access REBOL dtypes?

but within REBOL, so you can create a bspline by adding some some 
sort of object in a list of visible graphic elements which have properties.

Once View sources are released (part of the next release hopefully), 
do you think you could make some example, to show what you mean?

yep.

part of my plan... and why I haven't been to vocal about R3 view 
 ... I'm waiting to see how easy it will be to work on the new hostkit.

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

hum.. all 3D softwares I've used?

Max - try to define simple usage case, and possible syntax, so that 
Cyphre can see, how your aproach differs, because it seems to me, 
that with few enhancements Cyphre outlined above, Cyphre thinks current 
implementation can already do what you are asking for ...

as I said, I will wait for the hostkit with view to be released before 
spending to much time on this... I really don't have time to go in 
depth with this... and I'm not even trying to convince anyone.  just 
replying to questions and I feel its being taken too seriously for 
now.   its possible, the better approach will be to have access to 
some of the AGG internals via the extensions and wrap these into 
generic objects, for example.


its still just an idea.  there is no point to going into details. 
 I need to see the view host kit first.

I think that Cyphre just tries to understand your aproach, nothing 
more, and that he is really open to any ideas ...

yep  I agree, I just don't have the time to go in-depth.  too much 
stuff to do right now.

Maxim, no problem, I have not much time either now so feel free to 
clarify any time later.

I was just wondering what you are looking for to satisfy your needs.

And of course, you cannot request functionality of big complex 3D 
systems which are usually fat high-level layers over  low level graphics 
libraries.

You should think about the DRAW at the level of graphic library api, 
not application layer.

So I more awaited comparison with OpenGL, DIrectX, Cairo, Qt , Java2d 
 and so on. Anyway, I'm curious about your  examples....

Also I don't understand what is so wrong on using dialect as an interface 
when Rebol should be the case where working with blocks, dialects 
etc. should be a plus.

For example If you prefer interface based on function calls over 
dialect the I'd like to know what benefits you see in that approach 
etc.

Gabriele, i don't think so. (regarding the definition on wikipedia).
Actually, I used a technic very similar to what's done in R2.

In R2 the event engine throw tons of time events aswell. But the 
filtering (regarding which face as a rate property) is automatic 
(more or less).

Steeve, but were you succesfull to use this technique in real world 
case? I tried to use it for the DRAW demo but it doesn't work well.

Try: do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes-2.r


-try to move mouse over the window..you should see quick 'MOVE'  
events  eing logged in the console

-if you select any object using the mouse the loop is starting to 
do something usefull and from that time I could get only about 3 
MOVE events per second which is very slow. To me it looks like the 
event port blocks during execution of the code inside the WAKE handler.

But if I use the same code inside FOREVER+WAIT cycle the events are 
comming much more frequently.

The problem with FOREVER+WAIT in R3 though is it eats up 100% of 
CPU time(as opposed in R2) and I don't know why. Probably a question 
for Carl.

if you slow done your frame rate at 10 or 15 fps and increase the 
wait duration at 0.04, it might not hang up the cpu but il will be 
too slow.

Meaning only one thing to my mind, Rebol' s drawing engine is too 
slow when drawings are huge (slow by design)

*slow down

Henrik, in your last try, if you skip some time events  then the 
animation slow down but it's eating only 50% of my cpu (a small celeron).

tick: 0
...
handler: func [event] [
	switch event/type [
		time [
			++ tick
			if all [picked-obj tick > 30] [ 
				tick: 0
...

Rebol is slow for such animations

Moreover, you're using the graphic engine quite intensivly.
For each refresh:
-  2 calls to the draw the function + 2 shows


Maybe only one show of a composed gob (without the need to call draw 
seperatly) would increase the perfs.

Nope, the 2 shows are necessary and in fact optimizes the whole thing 
because you don't need to refresh whle screen everytime...better 
two smaller shows than one fullscreen redraw in this case.


The problem I was refering is not about performance..it is about 
blocking when executing longer code from AWAKE handler. I think this 
method is not usable.

When I run it using the forever+wait loop it works without problem 
at constant 28 fps here even if I wait for 10 miliseconds during 
each refresh. I only don't understand why 10ms is not enough to let 
cpu service the rest of system. Imo in R3 the CPU is not knowing 
about the wait/idle state from some reeason.

Well, i didn't say to refresh the whole screen but only one composed 
gob (and to discard the callings to draw).

but it's true that time events will not be faster than a forever 
loop.
It was already true with R2

The demo is about  thechnique where you can manage DRAW only objects 
in one gob so if I split the content to multiple gobs and compose 
them  it would ruin the whole concept.

As I said the problem is not in the demo itselt...it is in the timing/loop 
code.

You can  easily to see it if you put some code(doesnt have to be 
related to draw or even graphics) in your small example you posted 
previously. You will see the same slowndown which means: don't put 
time consuming code into the AWAKE handler. But where to put it if 
you generate time events in that place? :)

But are you sure your technic (of calling the draw function and then 
to show the image-gobs )is faster than letting the draw engine doing 
the whole job with one show?

definitely

ok i trust you ;-)

Note that the two draw calls also uses clipping so in fact the draw 
engine is rendering only the really needed parts.

so the clipping is done at rendering level and also at blitting level. 
While if you do a show on one big gob with draw you are rendering/bliting 
everything.

ofcourse if you want to do 100 smaller places on the screen then 
it is usually better to refresh whole screen ;)

Btw i think the throwing of time events can be optimized by modifying, 
the system handler:

>> ? :system/ports/system/awake
make function! [[
    sport "System port (State block holds events)"
    ports "Port list (Copy of block passed to WAIT)"
    /local event port waked
][
    waked: sport/data
    loop 8 [
        if not event: take sport/state [break]
        port: event/port
        if wake-up port event [
            if not find waked port [append waked port]
        ]
    ]
    if not block? ports [return none]
    forall ports [
        if find waked first ports [return true]
    ]
    false

instead of pushing back, 8 times, the time event (the worst case), 
we could push it only one time

well, try it..need to leave now. I still think the tie event generation 
is not usable until you move the receiving place from AWAKE handler 
to other place (as it was in R2 - face/feel/engage)

(Using time events)

Cyphre, By reducing the number of objets to draw (10 objects) I have 
a really smouth animation taking less than 2% of UC when an object 
is rotating, and growing to 20% maximum when the object is actually 
moving.
Meaning your clipping technic has a  low effect on perfs.

and with 50 objects, i have 30% to 50% CPU usage.
Time events are not so bad.

http://sites.google.com/site/rebolish/test-1/draw-shapes-22.r

Steeve,

clipping: I disagree here,you cannot compare the clipping effect 
by increasing/reducing number of renedered objects. The only valid 
test is to to compare rendering of same number of objects with and 
without the clipping being enabled. Note that the perfomance slowdown 
you are reporting when adding more objects doesn't have to be related 
to clipping.


regarding your new version..sorry, I'm still not convinced. It looks 
to me you just replicated the same busy loop as when I use FOREVER+WAIT 
technique. You are simulating kind of 'wait' using the tick skipping 
but the result is same when looking at the CPU usage.

I still wonder why we need to 'wait' too much in R3 unless CPU load 
starts dropping down.

When I have time,I'll try to create some test script which can be 
indentically used in R2 and R3 to see if there is really any difference.

Steeve: a busy loop means that the CPU is busy looping. That is what 
happens in your example. There is no "sleep" time between time events. 
That is not true with actual time events, which fire at a defined 
interval, and allow the CPU to sleep between them.

replacing a wait with a counter... oh well... :)

Steeve - your script reports some error here:


>> do http://sites.google.com/site/rebolish/test-1/draw-shapes-22.r
Script: "Untitled" Version: none Date: none
** Script error: Moved has no value
** Where: catch either either applier do
** Near: catch/quit either var [[do/next data var]] [data]