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."
> -----Original Message-----
> From: Maxim Olivier-Adlhoch
> Sent: Thursday, January 15, 2004 1:48 PM
> To: Rebol-List (E-mail)
> 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).
>
> 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."
>
>
> --
> To unsubscribe from this list, just send an email to
> [EMAIL PROTECTED] with unsubscribe as the subject.
>
>
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
