Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[view] accelerating view...

 [1/13] from: maximo:meteorstudios at: 15-Jan-2004 13:47


I REAAAAALLLYYYYY need to get view refresh more quickly. I know we all bitch about its slowness, I've got a few tricks, but I have to do an interactive application which is drawing one single line interactively. the simple "mouse down to start and mouse up" to draw a line. my canvas has to be at least 1000x800 and its really slow on my dual 800 with WILDCAT graphics card. right now while dragging the mouse there is no more than 2 frames a second refresh speed, if the show face is enabled. The actual event and process loop is 100 real time if I remove the 'show face line (meaning that the actual process of creating the draw effect block is microscopic in terms of slowing down the refresh.) can you guys give me some of your tricks to improve refresh speeds in any interactive apps? I'm into doin pretty wild stuff (like freezing the ui as a bitmap while I'm drawing or whatever, creating an overlay plane, anything works)... I tought about using the timer in order for the algorythm to forget about drawing all those refreshes when the cursor is going slowly (which really creates a large amount of lag) any advanced or wild suggestions are welcome is there a way to look-ahead for events and forget events in some circumstances (like if there is already a more recent mouse move event, I'd skip all those in the cue and perform only the latest one... that is a very common process amongst true signal based event handling). can creating my own handler allow me to streamline the event handling so that less useless events are generated, thus reducing lag? Thanks in advance !!! -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [2/13] from: didec:tiscali at: 15-Jan-2004 20:27


Re: [view] accelerating view... Hi Max
> I REAAAAALLLYYYYY need to get view refresh more quickly. >
The 'eat function from Romano and Gabrielle is here for that. Not sure it's the last version (not found on his web page), but here is one : eat-ctx: context [ free: true set 'eat func [/only blk [block!]] [ if free [ free: false any [only blk: [move]] until [ only: pick system/view/event-port 1 not all [only find blk only/type] ] if only [awake only] free: true ] ] ] To use it: put the 'eat func where you want events to be eat (usually in feel/engage, before a "show face"). DideC

 [3/13] from: maximo:meteorstudios at: 15-Jan-2004 14:31


I should say that I did tests on a super easy vid script: count: 100 s: now/time/precise repeat i count [ off: 10x1 off/y: i * 5 ui/effect: compose/deep [gradient 1x0 0.0.0 222.222.222] ;ui/effect: compose/deep [draw [pen white line (off) 1000x500]] show ui ] e: now/time/precise print t: to-decimal e - s print count / t my computer gives me 17 frames a second... but this should be like 20000... I mean, one line on a plain background. I've been using vid a long time and have done a lot of pretty advanced things with it, but its the first time I realise just how slow it really is. now I'm thinking of creating a face which resizes to the size of the line (diagonally) and which floats over the the rest of my ui. -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [4/13] from: roland:hadinger:arcor at: 15-Jan-2004 20:41


hi max, On Thursday 15 January 2004 19:47, you wrote:
> can you guys give me some of your tricks to improve refresh speeds in any > interactive apps?
Perhaps you could use something like: http://home.arcor.de/roland.hadinger/rebol/includes/guard.r A demo of using guard to control recursive do-events: http://home.arcor.de/roland.hadinger/rebol/includes/2.demos/guard.r This trick is used to actually speed up scrolling in this (experimental!) app: http://home.arcor.de/roland.hadinger/rebol/experiments/sonar1.r -- R.

 [5/13] from: greggirwin:mindspring at: 15-Jan-2004 12:54


Hi Maxim, MOA> can you guys give me some of your tricks to improve refresh MOA> speeds in any interactive apps? Don't refresh on every mouse move. Romano and Gabriele's EAT event-compressor approach can work well, but you can try other things as well (e.g. refresh based on a timer). You can also try making it a "feature". Rather than drawing the line itself, use end-point draggers (which are just faces) and show them. Only redraw the line if there is a pause in movement or the dragger is released. -- Gregg

 [6/13] from: maximo:meteorstudios at: 15-Jan-2004 15:46


tried the eat function... it does seem to help a bit, but I get this error all the time... ** Script Error: awake has no value ** Where: eat ** Near: awake only I'm using 1.2.10 is that an issue? merci :-) -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [7/13] from: greggirwin:mindspring at: 15-Jan-2004 13:50


Hi Max, MOA> my computer gives me 17 frames a second... but this should be MOA> like 20000... MOA> I mean, one line on a plain background. Big faces are slow to refresh; that's all there is to it. Whether you've got a plain background or not--of course adding lots of effects will slow things down even more--REBOL is doing a lot of work behind the scenes (everything is double-buffered I think). Until RT decides to make this a priority (and we could all argue about our *own* priorities :), we just have to deal with it. MOA> I've been using vid a long time and have done a lot of pretty MOA> advanced things with it, but its the first time I realise just MOA> how slow it really is. That's a great testament to it IMO. :) REBOL is magic. Like other "illusionists", it's very good at certain tricks and not so good at others. -- Gregg

 [8/13] from: maximo:meteorstudios at: 15-Jan-2004 16:08


hi, disregard my previous mail about eat... I went hunting on rebol.org and found the mouth full I needed... The complete 'Eat tool was on the site, it is working, and yes, it IS helping in removing the lag. But my app still stutters. ;-) On the upside, many of the users have a (much) faster machine than I so it should be less painfull for them. thanks for the tip about 'eat, I would not have found out about it. -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [9/13] from: ptretter:charter at: 15-Jan-2004 16:07


I think if you really want performance than you should use lower level view functionaly and stay away from 'layout and build your own faces. I'm curious of anyone has built a comparision of the performance. Paul Tretter ----- Original Message ----- From: "Maxim Olivier-Adlhoch" <[maximo--meteorstudios--com]> To: "Rebol-List (E-mail)" <[rebol-list--rebol--com]> Sent: Thursday, January 15, 2004 12:47 PM Subject: [REBOL] [view] accelerating view...
> I REAAAAALLLYYYYY need to get view refresh more quickly. > > I know we all bitch about its slowness, I've got a few tricks, but I have
to do an interactive application which is drawing one single line interactively.
> the simple "mouse down to start and mouse up" to draw a line. > > my canvas has to be at least 1000x800 and its really slow on my dual 800
with WILDCAT graphics card.
> right now while dragging the mouse there is no more than 2 frames a second
refresh speed, if the show face is enabled. The actual event and process loop is 100 real time if I remove the 'show face line (meaning that the actual process of creating the draw effect block is microscopic in terms of slowing down the refresh.)
> > can you guys give me some of your tricks to improve refresh speeds in any
interactive apps?
> I'm into doin pretty wild stuff (like freezing the ui as a bitmap while
I'm drawing or whatever, creating an overlay plane, anything works)...
> I tought about using the timer in order for the algorythm to forget about
drawing all those refreshes when the cursor is going slowly (which really creates a large amount of lag)
> > any advanced or wild suggestions are welcome > > is there a way to look-ahead for events and forget events in some
circumstances (like if there is already a more recent mouse move event, I'd skip all those in the cue and perform only the latest one... that is a very common process amongst true signal based event handling).

 [10/13] from: maximo:meteorstudios at: 15-Jan-2004 17:49


hi paul, that is a worthy assumption but in reality, VID and face really are the same beast. This specific problem is 100% face only driven. But in reality, it does not make any difference, because vid is really only a layout engine. It adds a few higher-level gizmos, but still uses the basic face/feel events and all of the basic face effects, just like if you use them manually. I think focus is specific to VID but its been awhile since I've played with that so I'm not completely sure. most of my rebol/view GUIs use VID and direct face setups about 50% equaly. In the very near future, I will start using liquid-vid more and more and eventually should phase out most basic VID useage, which I'd keep for modal Q&D panels. I also have a system where I extract vid faces and use them directly as my base face. This way I can cleanly re-insert them into vid layouts. if anyone can show speed differences in specific areas, then please share the info, we all want to know for sue ;-) my only beef with VID is that some styles use the redraw feel a litle too liberally, IMHO, and on large layouts, this CAN kill some noticable amounts of interactivity. -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [11/13] from: atruter:labyrinth:au at: 16-Jan-2004 12:22


Hi Max, I use code like the following to benchmark pre and post draw FPS: <code> REBOL [] img-size: 1024x768 img: to-image layout [origin 0 box img-size blue form img-size] view/new/options center-face layout [ origin 0 i: image img img-size effect [none] ;draw [circle 100x100 100]] ; i: image img img-size effect [draw [circle 100x100 100]] ][no-title no-border] start: now/time/precise loop 100 [i/image: img show i] end: now/time/precise unview print to-integer 100 / (to-decimal end - start) </code> My rough rule of thumb is that draw will halve your optimal [View] FPS with further degredation as the draw block size increases. I use a couple of tricks to optimize refresh rates: 1. Take a snapshot of a more complex underlying face and draw on that 2. Once the draw block gets to a certain size, perform 1) again and clear the draw block 3. For "line-move" or "freehand draw" type operations, make the 'show conditional on being a certain [user specified] distance from the previous point (this allows freehand polygon drawing without "over registering" the points) 4. Ensure your s/w is run on appropriate h/w (see next) I use the following rough approximation to determine what the 1024x768 FPS of a PC should be: (GHz * Memory Speed) / 10 Sample data: P4 3G/DDR400 (3 * 400) / 10 = 120 [actual is 102] C3 1G/DDR266 (1 * 266) / 10 = 26 [actual of 4] C3 1G/DDR266 (1 * 266) / 10 = 26 [actual of 16] ; post driver update Celeron 700/33 (.7 * 33) / 10 = 2.3 [actual of 2] AthlonXP1600 / DDR266 (1.6 * 266) / 10 = 42.5 [actual of 41] FSB / Memory speed is just as important as CPU speed, so for graphics intensive tasks ensure your clients don't use a Celeron / Duron! (driver updates can also sometimes make a big difference). Regards, Ashley<

 [12/13] from: antonr::iinet::net::au at: 16-Jan-2004 17:50


This is from a post by Allen Kamp 22 Jan 2003: One trick which works with some draw operations is to make sure the offset of the main drawing area is at 0x0 or Origin 0x0, I have scripts here which made the speed increase by doing this. Anton.

 [13/13] from: g:santilli:tiscalinet:it at: 16-Jan-2004 9:48


Hi Maxim, On Thursday, January 15, 2004, 7:47:55 PM, you wrote: MOA> right now while dragging the mouse there is no more MOA> than 2 frames a second refresh speed, if the show face is Are you sure it's really that slow? Try to count the number of times you're calling SHOW, you could be surprised. I bet it's just that you're getting too much events. Romano's EAT function or my event compressing WAKE-EVENT would probably fix the problem for you. MOA> is there a way to look-ahead for events and forget MOA> events in some circumstances (like if there is already a more MOA> recent mouse move event, I'd skip all those in the cue and MOA> perform only the latest one... that is a very common process MOA> amongst true signal based event handling). Pasting my WAKE-EVENT here. (You can change the NO-QUEUE object to decide what events should not be queued.) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/ ; Event filtering --- speeds up view! context [ no-queue: context [move: offset: none] wake-event: func [event /local no-btn] bind [ either not pop-face [ do event empty? screen-face/pane ] [ either any [pop-face = event/face within? event/offset win-offset? pop-face pop-face/size] [ no-btn: false if block? get in pop-face 'pane [ no-btn: foreach item pop-face/pane [if get in item 'action [break/return false] true] ] if any [all [event/type = 'up no-btn] event/type = 'close] [hide-popup] do event ] [ if pop-face/action [ if not find [move time] event/type [hide-popup] do event ] ] none? find pop-list pop-face ] ] in system/view 'self system/ports/wait-list/1/awake: func [port /local event events lasttype] [ events: clear [] while [event: pick port 1] [ either all [in no-queue event/type lasttype = event/type] [ change back tail events event ] [ lasttype: event/type insert tail events event ] ] foreach event events [ if wake-event event [return true] ] false ] ]