[REBOL] Re: speed up view
From: rotenca:telvia:it at: 6-Jul-2002 12:43
Hi Brett
> I have found that it is not entirely reliable though (event with the bug fix
> of events: copy []). You can get the slider very far away from the mouse.
> I haven't tried /forever option, not sure how, where, when you can use Eat
> apart from your example.
Yes there is a problem in this version. The 1.2.5 beta slider seems to me less
sensible. Do you confirm? I ask myself why.
The /forever refinement hasn't this problem, i am almost sure.
But if you use /forever, all faces will receive the compressed queue of
events.
In many cases it could be the right thing to do. But if you have, for example,
a drawing pen which wants all the intermediate position of mouse, it cannot be
what you want.
I have a one-shot version without this problem, at least to my experience, but
it deletes the events, instead of compressing them. I post it at the end of
this message (it does not check the state of modal panel, like the awake
function, this code could be added i think).
> So I haven't tried it with a real app either.
> It seems though that the app should process as many events as it can handle,
> without slowing the user. So for moving a slider, a list or some other data
> window might be refreshed. Now some computers might be able to do this once
> per second, others might be able to do four or perhaps 10 times a second.
> Then again if the data comes over a network connection it might take a few
> seconds. So I guess I am asking, will your eat function be suitable for
> these situations?
I think that all this problem must be adressed by RT with native code. This is
an hack to speed things, but is an hack. If your code must run only under 1.8
Ghz with 1024 Mb DDR RAM, it can be unuseful.
My first approach to the problem was checking the time of event. The idea was
to leave the user code to compress/discard the events with a time lesser than
the time of the last return of event code. Slow machines could compress more
events, fast machines could compress nothing.
But the time of events is not useful, because Rebol waits the end of your
event code to set the time of a new incoming event. So you receive always
events with a time greater than your last return time.
I see 3 strategies:
1) delete all queued events before returning from event code (see the
eat-delete code)
2) compress all queued events of the same type in a single event before
returning. (eat)
3) compress all events of the same type at the origin (eat/forever)
Do you see others solutions?
---
Ciao
Romano
----
free: true
eat-delete: func [/only blk /local tmp][
return
if free [
free: false
if not only [blk: [move key scroll-line scroll-page]]
until [
any [
not tmp: pick system/view/event-port 1
not find blk tmp/type
]
]
do tmp
free: true
]
]
