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

[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 ] ]