Re: Spinning the busy indicator

> On 2 May 2015, at 2:42 am, Kyle Sluder wrote: > >> Well that’s an interesting result - creating my own NSOperation with a >> QoS of NSOperationQualityOfServiceBackground and adding it to my queue >> produces a perfectly smooth and non-blocking app. If I use >> -addOperationWithBlock: things ar

Re: Spinning the busy indicator

On 1 May 2015, at 12:53 AM, Graham Cox wrote: > > So, the docs say (ha! here we go again…) that the default QoS is > NSOperationQualityOfServiceBackground. This appears to be the LOWEST QoS > constant. However, it also states that it is only used if the NSOperation > itself doesn’t set this va

Re: Spinning the busy indicator

On Fri, May 1, 2015, at 01:41 AM, Graham Cox wrote: > > > On 1 May 2015, at 3:53 pm, Graham Cox wrote: > > > > It looks as if to be sure I’m going to have to drop down a level and create > > my own NSOperations. > > Well that’s an interesting result - creating my own NSOperation with a > QoS o

Re: Spinning the busy indicator

> On 1 May 2015, at 19:13, Uli Kusterer wrote: > > On 01 May 2015, at 04:15, Graham Cox wrote: >> When the calculation for a tile is finished, it calls its delegate to tell >> it it has finished. The delegate is the original view. I use >> -performSelectorOnMainThread: to notify the delegate.

Re: Spinning the busy indicator

On 01 May 2015, at 06:46, Graham Cox wrote: > I use NSOperationQueue with the default -maxConcurrentOperationCount which is > NSOperationQueueDefaultMaxConcurrentOperationCount, i.e. let the system > figure it out. That appears to create 4 threads for my particular machine, > which has a Core i

Re: Spinning the busy indicator

On 01 May 2015, at 04:15, Graham Cox wrote: > When the calculation for a tile is finished, it calls its delegate to tell it > it has finished. The delegate is the original view. I use > -performSelectorOnMainThread: to notify the delegate. Idea: Have you tried using performSelectorOnMainThread

Re: Spinning the busy indicator

On Apr 30, 2015, at 23:41 , Graham Cox wrote: > > I’d be interested to know if this has changed from 10.9 or earlier (I’m on > 10.10). Oh, QoS is 10.10+ only. Before that there was threadPriority and queuePriority for NSOperation, and the old GCD dispatch queue priorities correspond to the ne

Re: Spinning the busy indicator

On Apr 30, 2015, at 23:41 , Graham Cox wrote: > > But if I leave it at the default, the same blocking problem is apparent. > Logging the default QoS, I see it’s -1, which equates to > NSQualityOfServiceDefault. Setting it to > NSOperationQualityOfServiceBackground things are fine. Therefore at

Re: Spinning the busy indicator

> On 1 May 2015, at 3:53 pm, Graham Cox wrote: > > It looks as if to be sure I’m going to have to drop down a level and create > my own NSOperations. Well that’s an interesting result - creating my own NSOperation with a QoS of NSOperationQualityOfServiceBackground and adding it to my queue p

Re: Spinning the busy indicator

In addition to GCD which is a good idea, you might look into the Accelerate framework to see if it offers something. There's a fairly recent WWDC video about it. Sent from my iPhone > On 2015/05/01, at 14:53, Graham Cox wrote: > > >> On 1 May 2015, at 3:28 pm, Quincey Morris >> wrote: >>

Re: Spinning the busy indicator

On Apr 30, 2015, at 22:53 , Graham Cox wrote: > > It looks as if to be sure I’m going to have to drop down a level and create > my own NSOperations. You can create your own (non-serial) GCD queue with any desired QoS, then set your NSOperationQueue to use it.

Re: Spinning the busy indicator

> On 1 May 2015, at 3:28 pm, Quincey Morris > wrote: > > — I don’t see anything really wrong at any point, other than it looks > unresponsive because it’s very busy for a while. Well, thanks for having a look and taking an interest - and apologies for the rather scrappy coding. > > I would

Re: Spinning the busy indicator

On Apr 30, 2015, at 21:46 , Graham Cox wrote: > > If anyone’s interested in having a look at what’s happening, I’ve put the > project sources up here: http://apptree.net/code/Gingerbread.zip > Here’s what I see: — I took out your 3-thread limitation.

Re: Spinning the busy indicator

On May 1, 2015, at 00:08:33, Graham Cox wrote: > > Well, it’s always gratifying to find I’m not alone ;) > > How did you figure out a value that leaves one for the main thread? The > actual value returned is -1 for > NSOperationQueueDefaultMaxConcurrentOperationCount, not the actual number it

Re: Spinning the busy indicator

> On 1 May 2015, at 3:02 pm, Steve Mills wrote: > > I’ve run into this too, where letting the OS figure out how many operations > to queue at once doesn’t always work like a human wants it to work. I ended > up doing what you did - leave one for the main thread. > NSOperationQueueDefaultMaxCo

Re: Spinning the busy indicator

On Apr 30, 2015, at 23:46:53, Graham Cox wrote: > > Well, here’s a huge clue. > > I use NSOperationQueue with the default -maxConcurrentOperationCount which is > NSOperationQueueDefaultMaxConcurrentOperationCount, i.e. let the system > figure it out. That appears to create 4 threads for my par

Re: Spinning the busy indicator

> On 1 May 2015, at 1:12 pm, Quincey Morris > wrote: > > Yes, they do say that. But as it happens I went to IB (6.3.1). The > “indeterminate” checkbox is right there, and if you uncheck it you get a > clock-style progress indicator. I guess the docs are out of date, though only > by about 4

Re: Spinning the busy indicator

Doing a little bit of googling on some of the stuff in your stack trace, InstallEventHander and GlobalRegistryEventRegistered all seem to be part of HIToolBox. I just picked a random app of my own and stuck a few breakpoints in it to find every menu invocation in my app goes down pretty much t

Re: Spinning the busy indicator

On Apr 30, 2015, at 19:15 , Graham Cox wrote: > > Well, the docs say: > >> This method only has an effect if style returns NSProgressIndicatorBarStyle. >> If style returns NSProgressIndicatorSpinningStyle, the indicator is always >> indeterminate, regardless of what you pass to this method. Y

Re: Spinning the busy indicator

> > Stumped. > > —Graham > I don’t have a lot more ideas than you, having been reading this thread (no pun intended) for 2 days. Is this only happening when you click to bring up a menu when your app is running or at other times too? I can’t currently think of a good reason why opening a

Re: Spinning the busy indicator

> On 1 May 2015, at 10:18 am, Quincey Morris > wrote: > > On Apr 30, 2015, at 16:39 , Graham Cox wrote: >> >> As I mentioned it’s the spinning busy indicator, which is always >> indeterminate. > > The circular style isn’t always indeterminate, though (I forgot) it looks > different when it

Re: Spinning the busy indicator

On Apr 30, 2015, at 16:39 , Graham Cox wrote: > > As I mentioned it’s the spinning busy indicator, which is always > indeterminate. The circular style isn’t always indeterminate, though (I forgot) it looks different when it’s not indeterminate. I just tried forcing an app with a spinning inde

Re: Spinning the busy indicator

> Did you set your progress indicator to indeterminate? If not, it’s not going > to animate. > As I mentioned it’s the spinning busy indicator, which is always indeterminate. Something odd is happening, which may or may not have an effect on the busy indicator (which is a minor annoyance, b

Re: Spinning the busy indicator

On Apr 29, 2015, at 18:22 , Graham Cox wrote: > > The indicator shows and hides correctly, but most of the time it doesn’t > actually spin. It does sometimes, but mostly it doesn’t. I’m wondering if > there’s something I need to do to keep it going that I’m not doing (I’m not > doing anything

Re: Spinning the busy indicator

> On 30 Apr 2015, at 11:22 am, Graham Cox wrote: > > My guess is that the busy indicator is animated by a low-priority thread of > its own, and the work being done by my queue has a higher priority so the > animation thread never gets any time. Does that sound like a reasonable > explanation?