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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
