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

[Alex Tweedly]

Rob Cozens wrote:

>
> Hi Robert,
>
>>  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.
>
>
> Maybe this is just a morning when I can't get it.
>
> But unless your handler is hard-coded to the specific loop or makes a 
> runtime decision on whether to update every 50 steps, every 100 steps, 
> or some number in between, I see no way the position of the progress 
> bar can accurately reflect the percentage of task completion in all 
> circumstances.
>
> What I posted was generalized logic that calculates the number of 
> steps required to move the progress bar one pixel, regardless of the 
> width of the bar.  That is the minimum steps required before resetting 
> the thumbPosition is visually manifested on the screen.  Anything more 
> produces "jerkier" movements.

The suggested method sets the scrollbar limits and updates the thumbpos 
just the same as you do. But it determines whether to do the update 
based on time elapsed since last update, rather than on a count of the 
records processed. Because of the way the eye perceives movement and 
change in a visual scene, this is usually, maybe always, adequate to 
avoid *visual* jerkiness, even though it can lead to theoretical jerkiness.

Your code (I had to look back to remind myself - so I've copied it here 
for convenience) was

>     put 0 into recordsProcessed
>     put round(recordCount/(the width of scrollBar "Progress 
>Scrollbar")) into progressInterval
>     put max(1,progressInterval) into progressInterval
>     repeat with x=4 to lastRecord
>       ... -- process one record
>       add 1 to recordsProcessed
>       if (recordsProcessed mod progressInterval)=0 then set the 
>thumbPosition of scrollBar "Progress Scrollbar" to recordsProcessed
>  
>


For example, let's say we had a scrollbar of 200 pixels, and 1000 
records to process. The your code will calculate progressInterval to be 
5, and will therefore do 200 updates - very smooth, no jerkiness at all. 
However, if we actually manage to process these things quickly - say in 
2 seconds - then you are doing 100 updates per second.

The other method would replace the last line with something like
         if ticks()-lastTicks > 5 then
              set thethumbPosition of scrollBar "Progress Scrollbar" to 
recordsProcessed
              put ticks() into lastTicks
         end if

So in the above example, it would do 12 updates per second, and hence 
each update would change the scrollbar position by about 8 pixels. (i.e. 
some abstract jerkiness)

The screen doesn't actually update 100 times per second, and you 
certainly can't see this as any smoother than doing 10 or 20 updates per 
second - so your method is going through the extra CPU cost for no 
*visible* benefit. (Personally, I don't think the cpu cost of this will 
be significant, perhaps not even noticeable. The cost of doing "set 
thumbpos" for *every* record can be significant - but doing it 100 times 
per second is probably not significant - a quick, unscientific benchmark 
suggests less than 5% of the cpu of my moderate speed laptop).

OTOH, if the processing would take a long time - say 200 seconds - then 
the time based method will do additional updates which produce no 
visible change - i.e. wasted CPU usage - but since it is limited to say 
12 times per second, this can be safely assumed to be insignificant 
percentage of the available CPU.

Summary: there isn't that much to choose between them One can waste a 
small percentage of the CPU (but only in relatively short-lived loops) 
while the other can only waste a very small percentage of the CPU (but 
does so mostly in relatively long-lived loops).

Aside - on WinXP, progress bars do no update to a pixel granularity, 
they update in blocks of around 12 pixels, so nothing looks all that 
smooth anyway.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.0/304 - Release Date: 07/04/2006