• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Interthread comms for progress bars
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interthread comms for progress bars


  • Subject: Re: Interthread comms for progress bars
  • From: Andreas Schweizer <email@hidden>
  • Date: Mon, 23 Jul 2001 18:54:53 +0200

Hi Ken,

I've got 4 image processing threads running, each on a different quarter
of the same image. I have a progress bar which I'd like to display in a
"0% - 100% processed" fashion. I know how many pixels there are in the
image, and each pixel takes the same amount of processing (there aren't
regions of interest in the image, all pixels are treated the same), so
I'm using a determinate NSProgressIndicator.

What is the best way of smoothly and accurately updating the progress bar
during the image processing pass? What I don't want to do is slow down
the image processing any more than I have to. I have considered (but not
yet implemented any of) the following:

[1] Have a document-level variable, 'pixelsCompleted', which each of the
4 threads increment by calling [parentDocument incrementPixelsCompleted]
after each pixel is processed. That method then figures out if another 1%
has been completed since the last time it updated the progress bar, and
if so it updates the progress bar. Bearing in mind the images are
typically 800x600 minimum that might incur a lot of processor overhead if
the function gets called 480,000 times for 1 image processing pass?!!


This works, but you would need to lock that variable for each access, as incrementing is not an atomic operation. I'd rather use one counter per thread that only the owning thread increments. In your main (drawing) thread, you could then sum up all the counters. Like that you can easily avoid the overhead introduced by using NSLocks.

[2] Have each of the 4 threads keep track of how many pixels it has
processed, and each time it finishes 1% of the image (out of a possible
25% per thread), get the progress bar to add 1%. This might result in the
progress bar 'jumping' a couple of % at a time (where all threads have
reported an extra % to the progress bar at the same time), but presumably
requires less processing overhead than the previous option.

I would use an NSTimer and update the progress bar from the main thread all, say, 500 milliseconds or so (after checking that the percentage has changed.)

Do I need the progress bar / whole UI running in another thread? I've
already got 1 main app thread and the 4 slave threads (one for each
quarter of the image). Or do I keep all UI stuff in the main app thread?

It's probably the best to avoid accessing AppKit from outside the main thread, as it is not thread-safe

HTH,
Andy


  • Prev by Date: menu enabling/disabling in Java
  • Next by Date: Re: Use of NSLog() for debugging
  • Previous by thread: Interthread comms for progress bars
  • Next by thread: Printer driver sample code?
  • Index(es):
    • Date
    • Thread