Hank Heijink (Mailinglists) wrote:
On Mar 31, 2008, at 2:06 PM, Mike wrote:
I suppose it's possible. The spawned thread does a lot of setup then
iterates some arrays of a bunch of objects in the filesystem that it
needs to delete. The idea is to update the progress bar one increment
with each item being deleted. I'm using a MacBook 2.16 Ghz but I doubt
that the main thread is too slow to be able to do the updates.
The issue wouldn't be the main thread being too slow, but the worker
thread being too fast, as it were. You'd be surprised how often you can
be wrong with this kind of stuff. I've wasted hours thinking "It surely
can't be x" and then actually measuring and finding it was x all the
time. How big is the bunch of objects your program needs to delete? How
long does it take to delete one item?
It could be anywhere from 1 to an unlimited number of items. I have no
idea how long it takes to delete each one and I don't have time to play
around with performance tools.
Also, I set a message text item with the name of each item being
deleted in the window as the worker thread runs. I never see it change
even for an instant. I find it hard to believe that there can't be any
visual update no matter how quickly the worker thread completes.
If you change the UI values with setNeedsDisplay: calls, they only get
updated once in every iteration of the main run loop. If there's a lot
going on on that run loop, you may see just one value change (the last
one) or none at all if you reset the values when you're done. If you're
using bindings I'm not sure about the timing, but it's definitely not
going to be faster than direct calls.
I am doing nothing in the main run loop when th worker thread fires. The
main thread is doing nothing but idling and this isn't a case of seeing
intermittent things change - NOTHING ever gets updates while the worker
is running. I don't really care about speed. Fast or slow doesn't
matter. What I want is to see the items update while the worker is
running, not after it's done. If I wanted nothing to happen until after
the operation was done, then I would just abandon threads altogether and
just call a single method on the main thread on completion.
Have you measured how long it takes for your worker thread to complete
its task? If it's less than a second, I'm not sure if you need a
progress bar at all. A progress bar combined with changing text doesn't
make a lot of sense if that updates faster than your user can read
anyway, so you might want to tone down the update speed.
Well, it could be fast on a Mac Pro but very slow on a PowerBook G4 400.
It could be fast because only one item is being deleted, or it could be
very slow because 1,000,000 items are being deleted. The point is: I
shouldn't have to care. It should just do the right thing and update
when I tell it to.
Hank
Hank Heijink (Mailinglists) wrote:
Just checking the obvious here - is it possible that your worker
thread completes its work so fast that the main run loop hasn't
updated the screen once before it's done? Keep in mind that the main
thread has to display your window with the progress bar and the text
and (depending on your implementation) that your worker thread may be
working (and completing) while that's being done.
On Mar 30, 2008, at 2:55 PM, Mike wrote:
I have all my UI running on my app's main thread. I have a worker
thread that I detach with
detachNewThreadSelector:toTarget:withObject: (my worker thread).
In my worker thread I do a tight processing loop and one of the
things I do in the loop is call two methods in the main thread to
update the display (a text message and progress bar) - via
performSelectorOnMainThread:withObject:waitUntilDone:modes.
However, when the loop runs in the spawned thread, the display
doesn't get updated. If I insert a sleep(1) call into the loop, then
the display updates.
Why doesn't the main thread process the changes to the UI unless I
call sleep? I thought the whole idea of using a separate thread was
so that the main thread could continue to run on its own?
Thanks,
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/hank.list%40runbox.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/hank.list%40runbox.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
