Re: Threading and NSViews
Re: Threading and NSViews
- Subject: Re: Threading and NSViews
- From: Karim Morsy <email@hidden>
- Date: Tue, 21 Mar 2006 08:58:21 +0100
I've just thought that the UI would be more responsive if the all
drawing was done seperate threads.
but it's good to hear that it doesn't really matter. the timer
approach is a lot easier to implement.
thanks!
Karim
On Mar 21, 2006, at 2:22 AM, John Stiles wrote:
I can't imagine that a separate thread would be any less troublesome.
AFAIK there's nothing inherently bad about running many timers
simultaneously. If you don't code very carefully, it can lead to
bugs, but threaded code certainly shares that problem :)
On Mar 20, 2006, at 4:41 PM, Karim Morsy wrote:
All the same, what makes you think that a timer would be
inefficient?
in one of my previous posts I've been told that I could get into
trouble if I was using to many timers too often per second. I
have 2 timers for drawing an olpenglview (every 0.05 seconds), one
timer that draws 4 views (every 0.02 seconds), and probably one or
two more that update information to the user and that are not as
performance consuming as the other timers ... do you see a problem
here and if so, would you know a solution to it?
thanks,
Karim
On Mar 20, 2006, at 10:46 PM, John Stiles wrote:
performSelectorOnMainThread would be the safest way to go.
All the same, what makes you think that a timer would be
inefficient? I think a timer would be more efficient than calling
performSelectorOnMainThread 50 times a second.
On Mar 20, 2006, at 1:28 PM, Karim Morsy wrote:
thanks for the hint, kaelin!
as far as threading is concerned, I have one more question about
views.
so far I've been drawing a view on the main thread and redrawn
it with a timer every 0.02 seconds. to save performance, instead
of firing the timer on the main thread I would like to perform
the drawing on a secondary thread that runs in a while(true)
loop, sleeps for 0.02 seconds and repeatedly redraws the view.
so far I've been doing this (to periodically draw 4 views):
- I detach the drawing thread
- within that thread I do:
BOOL canDraw = [mView[i] lockFocusIfCanDraw];
if(canDraw) {
[mView[i] updateView: &values]; // in updateview: I do some
calculations and then call setneedsdisplay on self
[mView[i] unlockFocus];
}
- sleep for 0.02 seconds
-repeat
so far, most of the time this has been working fine, except for
some tiny mis-drawings that sometimes occur (from which I
assume that I'm missing something here).
I've read several articles and docs about multithreading in
cocoa and it's said one has to be really cautious when drawing
on seperate threads.
so I'm wondering wether the approach above is a good and most
importantly correct one + is there a better / more efficient
alternative ?
thanks again,
Karim
On Mar 20, 2006, at 8:56 PM, Kaelin Colclasure wrote:
On Mar 20, 2006, at 11:52 AM, Kaelin Colclasure wrote:
On Tiger and later systems, you can use Darwin notifications.
Any thread can register for them, and they are trivial to post:
notify_post("self.fileInitCompletedNotification");
If you elide the "self." prefix, they can even cross process
boundaries.
I should rather say, "If you replace the "self." prefix with a
reverse domain name prefix (e.g. "com.example.")..." (This
mitigates the problem of name collisions.)
-- Kaelin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden