Revolution is very slow to refresh fields. How can I speed it up?

[Robert Brenstein]

>Alex & Geoff,
>
>>You don't need to know how many ticks it takes.
>
>OK, I'll bite: just how does one set the end value of the scrollBar 
>if one does not have an idea of how many loops or how many ticks the 
>entire process will take?
>
>Suppose, for example, one is downloading a file.  Changing the 
>thumbPosition every fixed number of ticks means that after x tricks 
>the progress bar will have the same setting regardless the file size 
>(eg: a 5MB file download will show exactly the same progress as a 
>10MB download or a 100MB download).
>
>Also, how does one know the progress bar won't get completely to the 
>end well before the process is completed?
>
>Rob Cozens
>CCW, Serendipity Software Company

I think you are confusing two different aspects of progress bars. The 
total progress is controlled by whatever parameter applies, be it the 
number of files or the size or whatever makes us define the progress. 
What was suggested is that the code that actually does the progress 
display is not updating the bar more often than every 5-10 ticks (or 
whatever is determined for a given system). That saves on system 
having to update the display more often than needed and thus gives 
extra cpu cycles to your program. Of course, this has to be applied 
differently to different situations. In the example of downloading a 
while that you mentioned, the internet connection can be a bottleneck 
and thus there is no point to concern yourself with the frequency the 
bar is updated. If I am running a process of 100 loops and my bar is 
200 pixels, then I want to update for each step. However, if my 
process runs 10000 loops, then updating for each step is pointless 
since the bar will not visibly move and updating every 50-100 steps 
will do.

Robert