Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- Subject: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- From: Jean-Daniel Dupas <email@hidden>
- Date: Wed, 14 Mar 2012 19:28:42 +0100
Le 14 mars 2012 à 17:52, Per Bull Holmen a écrit :
> Den 17:19 14. mars 2012 skrev Wade Tregaskis <email@hidden> følgende:
>
>> The reality is of course more of a compromise. It's quite common to do drawing across multiple threads, though you still synchronise the final "blits" around a single thread (i.e. the main thread).
>
> Isn't that still legal?
Not only it is, but it is builtin AppKit. See -[NSView canDrawConcurrently] for details.
> I remember it was legal in the old days of Mac
> OS X, and I did it once, and had no problems with it. From what I
> recall, I decided in the end that I had gained nothing from it, apart
> from added complexity. I'd think that would be less useful nowadays,
> since the drawing is supposed to be offloaded to the graphics card.
> Receiving events on other threads were discouraged, because things
> could happen out-of-order.
>
>> Likewise even event handling is often effectively multi-threaded, because you dispatch from the main thread to a variety of tasks, queues or worker threads.
>
> But then you are receiving the events on the main thread? What do you
> mean? If you receive events on the main thread, and dispatch the work
> to be done to other threads, I'd say that is quite in line with how
> things are currently done on OS X.
>
> Per
-- Jean-Daniel
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden