World: r3wp

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]

Gabriele, you can't be more wrong. There is obviously sleep times 
in my example.

I reported that the CPU usage is variyng a lot depending what time 
events are triggering. There's no need to argue again facts. Obviously, 
less CPU usage means the CPU is sleeping somewhere.

Henrik, same argument, It's not a busy loop. Have you Guys tested 
or not ?

Sorry, Cyphre, not Henrik

Pekr, you can't use Rebol to "do " the script at this remote location 
 , you must download it at first.
(no redirection supported by http in R3)

Steeve, ah, I see, you are basically processing your fake time events 
whenever other events happen (eg. mouse moves). But if that's the 
case, then there is absolutely no point in using those fake time 
events. Also, there is no guarantee you are going to get events...

It is still a very silly way to do what Cyphre is doing, more consistently, 
by just using a FOREVER loop with WAIT.

Dropping by. Looking back.

It looks like this discussion evolved a lot.  Let me know if there 
is a question I can answer about it.

And, it's possible there's a bug. See last line of:
>> dt [loop 10 [wait 0.1]]
== 0:00:01.000138
>> dt [loop 100 [wait 0.01]]
== 0:00:01.000423
>> dt [loop 1000 [wait 0.001]]
== 0:00:01.003355
>> dt [loop 10000 [wait 0.0001]]
== 0:00:00.01414  <-- wrong

not yet reported to curecode.

This might be related to the timing resolution change we made a few 
versions ago.

my output is different (VirtualBox WinXP):

>> dt [loop 10 [wait 0.1]]
== 0:00:01.00047

>> dt [loop 10 [wait 0.01]]
== 0:00:00.100501

>> dt [loop 10 [wait 0.001]]
== 0:00:00.010723

>> dt [loop 10 [wait 0.0001]]
== 0:00:00.000234

argh, forgot to loop more than 10 times. forget it.

It still goes wrong in that last case.

Anyway... on above CPU issue... the metric is this: R3 should be 
as good or better than R2 in this.

In other words, there's no reason it should't be.  Also, we know 
the code has a few problems on non-windows boxes.

BTW, the relevant code is host-device.c, line 406 and below.

*/	REBINT OS_Wait(REBCNT millisec, REBCNT res)
/*
**		Check if devices need attention, and if not, then wait.
**		The wait can be interrupted by a GUI event, otherwise
**		the timeout will wake it.

Specifically:
	// Nothing, so wait for period of time
	delta = (REBCNT)OS_Delta_Time(base, 0)/1000 + res;
	if (delta >= millisec) return 0;
	millisec -= delta;  // account for time lost above
	req.length = millisec;

Robert and I are discussing field persistence, i.e. tieing fields 
directly to database tables in a layout. Going to be a bit about 
our conclusions in the R3 GUI specs soon.

The question is: How to get from GUI to a DB and back without cluttering 
the VID code, or having to code to much. The idea is to collect the 
GUI elements belonging to one record and than auto-create tables 
and columns. So, people can concentrate on the app code and get the 
75% always necessary database code for free.

If you have any ideas, hints let us know.


We have a first prototype running, but we want to make it more elegant.

Well, if you show us something it will be easier to propose ideas.
I'm working on my own GUI aswell currently :)

My main idea (Already tried in the past ) is to build enough small 
primitives to allow to constuct all the standard styles without the 
need to add bloated hand written code.

The primitives are context sensitives, meaning that blocks of primitives 
can be shared between several face without the need to bind/copy 
them for each face.

The way that accessors on panels work in R2 is a good start (almost):

	>> lay: layout [pan: panel [foo: field "Foo" bar: field "Bar"]]
	>> set-face pan ["Bar" "Foo"]
	>> get-face foo
	== "Bar"
	>> get-face pan
	== [foo: "Foobar" bar: "Barfoo"]

Tie that to validation, eg:

	import get-face pan [foo: string! [some char] bar: opt string!]

Or an active record:

	record/update get-face pan

Not perfect as is, and perhaps simplistic, but I could imagine finding 
a way to add more semantic hooks to a layout and have a somewhat 
automated way to set/retrieve data from parts or all of the gui...

Especially recognising that the layout structure may not represent 
the application data structures.  I've toyed with the idea of a 'ref 
keyword - ui: layout [field ref 'user/name] - ui/get 'user/name, 
ui/set 'user/name, ui/get 'user == [name ...]

i think the syntax of the data block to get/set the GUI and get/set 
the DB should be the same.
>>get-face pan
== [foo: "foo" bar: "bar"]
>>set-face pan [foo: "bar" bar: "foo" ]

>> get-db [foo: "bar" bar: "foo"]

== [foo: "bar" bar: "babar"]   ;the DB can decipher the data block 
and knows well what is the requested key and what is only attribute.

>>set-db [foo: "foofoo" bar: "..."] ; update the record or create 
a new one.


Having exactling the same syntax allow to pass data between the GUI 
and the DB without pain.

specs:

http://rebol.net/wiki/R3_GUI_Specs#Field_Persistence

Steeve: any reason why set-words over words?

Hmm... Ok

Henik, I'm not sure of the interest to add record specifications 
on each field. a simple record tied with the panel should be enough.

E.g with your example:

 name-panel: group 2 [
   label "ID"   id: field 
   label "Name"   name: field
   label "Address" address: field 
   label "Post Code"  postcode: field 
   label "Comment" comment: area 

 ] record name-table [name: key Address:  postocode: comment: data]

Chris, what do you mean ?

In your examples you use set-words...

Ah, ok.

It's because it's easy to convert them into objects. Don't know if 
it would be usefull or not.

Henrik: Do you also tie validation and multiple data sources to each 
binding?  I kind of like the independence of a data model co-existing 
with a layout structure, you can poke and prod data from outside 
while the view internals just get on with what they do...