World: r3wp

I've been looking into this and remembered the source of my fix... 
I don't use the VID popup-feels in glayout, cause its wake event 
is smart enough to handle things properly.

VID sets the window feel to one of many different feels... :-( so 
I've got to patch VID again )

arrgh.

you must use hide-popup to close an inform.

Max, that's intentional. by default, there needs to be a way to get 
rid of the modal popup. if you don't provide any, the system will 
get rid of it on click. do you have an example where you want a modal 
popup (blocking your app) with no clickable face in it?

I did a full analysis of the problem (again, since I had done so 
with glayout a looooonng time ago) and there is no simple ways to 
handle the issue with the current view setup.

part of the problem is that closing the window via the title bar 
doesn't propely call hide-popup.

so I built a new pair of funcs and do the event blocking for non 
pop ups in my event-handler.

I don't have a PC keyboard, but does View support overwrite/insert 
switcing?

not AFAIK, but using windows api, you surely can.

hmm... I thought it was a matter of doing some changes in CTX-TEXT. 
but if I get this right, it won't matter.

.

Max, how much time ago did you do your "analysis"? The modal system 
was rewritten almost from scratch in view 1.3. Did you post the bugs 
you had found?

a long time ago. the problems where that it was missing some things 
like opt support in show-popup and some other thing.  and the show-popup 
selection of feels didn't make it very predictable.


with my custom wake-event/window-feel pair, it just went haywire. 
 so I rewrote both so that they would work better within glayout's 
revised management of view layer.


for example in glayout... the view function has a /modal   and a 
 /center  refinements... these make many things much simpler to use... 
I rarely use show-popup within the app, cause the glayout's view 
command supports it directly.

(modality that is.)

Is Cyphre's gui console source around anywhere?

start a desktop, go to Sites/Cyphre ... there is vconsole script 
...

ahh.. simple

anyone know a way to trigger event code at a rate faster than 15 
times a second within a view wait?... the view rate is REALLY imprecise 
and doesn't go above 15 ticks a second in my tests. 


strangely  this has nothing to do with possible refresh rate which 
can bo well beyond 15 frames a second.

What do you try to do ? An animation ?

that and / or better interactive feedback when the refresh can support 
it.

right now I'm testing a forever loop ...

but if there is something builtin that can precisely trigger precisely 
the rate we ask it, I'd prefer to go with that.

right now asking for a rate is always about 66-75% off, even using 
wait 1 / 30 or 1/100 will consistently be off by a window of 66% 
to 75%

there is not to my mind.

i have this limit too in some scripts

its funny cause if I do a timed wait 0, I go up to over 100000 iterations 
a second.

so clearly, the rebol event engine is capable of much higher throughput 
than its allowing.

he can but it's a design limit.

the rate you enter on a face is not taken in account. 
Time events are always throwed at the same rate.

Then there is some internal counter for each face which have a rate 
value, to know when the time events must be dispatched to them.
I don't know if i'm clear...

the rate is taken into account if you set it before opening the window, 
but cannot be changed after.

but beyond 5 / second, is progressively gets off by the above percentages. 
 up to a maximum of 15/s when you put it at 24

but I am now building a precise timed function which is taking 1% 
cpu and can go up to  60 frames/second consistently.

wrong, it can be, but you must do a refresh on the face, after changing 
his rate

beyond that and the wait goes into madness mode and consumes 100% 
(of one core)

What i mean, is that, there is 2 rates.

One for the inner event handler which is always the same (the limit 
you pointed 15 ev/sec)
And the rate of the face, wich is basically a counter

this might have been fixed in a later view, cause it didn't update 
before.

ah ok.

So even if you fix a low rate 1 ev/minutes on a face, The time events 
continue to be send at a rate of 15 ev/sec in the inner event handler.
It can be the reason why it consumes so much time

i got the problem in area-tc

and there is another one problem, It consumes time and memory, you 
have to to do frequent recycles.

I've never had any memory issues with recycling...
do you put recycle to off?

(when rate is used)

no, but i saw that when the time rate is activated it consumes memory, 
some mega, i don't like that

seems the lack of resolution from the /precise flag is the source 
of the offset in what you ask and what you get.  I bet on a linux 
box, it would be much more precise.

Max rate of 15/s sounds a bit low to me. When I was on WinXP it was 
48/s maximum rate.

if I put rate at or anything above 30 I only ever get 15, and when 
I do tests with my more precise timing function it seems that by 
using wait 0.001 I can go  at 65 frames / second.  


ironicaly, rounding and IEEE math errors give me the same 66% - 75% 
offset between desired rate and actual rate... seems I'm using the 
same algorythm than REBOL internally.

this is on a winxp with 1.5GHz core2 duo.

(and good nvidia gfx card)

I have a strange reaction in some AGG code...  calling show on the 
face is actually appending the new AGG drawing to previous such that 
the image is the result of all prior draws... but the draw stroke 
(verified) isn't growing!


anyone know what is causing this... AFAFIK I am not using the draw 
command, but setting the face/effect and calling to-image on the 
face.

DOH!  never mind... just found it... I was setting the face/image 
to that new image  ...  heheheh  obvious.