World: r3wp

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

i will post it tomorow, it tried only on XP

is that some new feature? I'm using 2.100.97.3.1 release under Win 
XP

i don't think so, actually it's a trick i discovered accidentaly. 
I don't thing Carl thought about it

i used 97 too

do I need to set the event properties in some specific way?

i just made
make event! [type: 'time port: port-event]
(yes you need to add the port-event, if not it doen't work)

doesn't work here even if I put the reference to event port inside 
the event

Hmm... i will post my complete test then.

How did you created the port-event ?

I just put there reference to system/view/event-port

event-port: system/view/event-port: open event:// 
And then you added you handler at  port-event/awake
right  ?

I'm using the official init-view-system so the sequence looks like:
init-view-system
p: system/view/event-port

insert system/view/event-port/state ev: make event! [type: 'time 
port: p]
...

by default there is nothing at system/view/event-port

Hum ok, i don't use it because i don't like it, i do my own ;-)

yes, but try: source init-view-system
this is a shortcut for creating the event-port

i takes one line to make it

I want to be compatible with VIEW so I'm using the system handler. 
But anyway, this shouldn't make any difference no?

hum ok, it should not be a burden

no, i see no difference

unles you are using some 'special' handler :)

We will see :-)
But obviously there is something different cause it works here

goto bed
GN

me too...cu

Steeve, how is your approach different from a busy loop?

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 ...