Re: NSOperation Efficiency
On Dec 4, 2012, at 23:02 , "Gerriet M. Denkmann" wrote: > And got almost the same overhead (tested three times with 99 operations); > clock time per operationexpected time overhead factor > //8 ops 29.9, 30.1, 29.712.52.4 > //7 ops 29.2, 30.0, 29.714.32.1 > //6 ops 28.8, 28.5, 29.016.71.7 > //5 ops 28.6, 28.4, 28.920 > 1.4 > //4 ops 29.4, 31.9, 30.825 > 1.2 > //3 ops 35.7, 35.4, 35.233 > 1.06 > //2 ops 51.7, 51.5, 51.250 > 1.03 > //1 ops 100 > > Looks like NSOperationQueue has some problems, or? Your expected times are questionable: 1. You "expect" a multi-threaded execution to have no measurable overheads at all. Since your expectations are unreasonable, you don't know whether the actual times are good or bad. 2. You don't state whether you create all of the operations before letting any run, or if you're creating them while some are already running. That's going to affect what you measure as overheads. The questions of overheads in queuing operations (which Kyle has being saying is inefficient) is an entirely separate matter from what you seem to be measuring here. 3. Even if you had all of the operations ready to start, there might be a different set of overheads in actually starting them, apart from creating them in the first place. 4. How many cores on the Mac you used for the test? 2? 4? 8? 5. Each core can support 2 threads via hyperthreading, but nothing guarantees that simultaneous threads in a single core are so completely parallel as to execute twice as fast as 2 threads in 2 different cores. In fact, it's almost certainly true that 2 threads in the same core run significantly slower, since they're competing for certain parts of the core's hardware. 6. How do you know that the cores are all running at the same clock speed throughout your tests? My understanding is that, in recent Intel CPUs at least, the fewer cores you use, the faster they go. 7. You don't know how OS X prioritizes thread switches in an extremely compute-bound scenario like this, as opposed to a mixed-use scenario where threads voluntarily give up their time slice pretty often. 8. You don't take into account what else might be using CPUs during your test. 9. Beyond a certain level of usage, OS X might be throttling your execution to ensure that it doesn't excessively hinder the "near-future" execution of other apps, or its own internal processes. What I think you can take away from this test is that using more than 3 simultaneous threads doesn't really help reduced the *elapsed* time of the whole set of operations. On this Mac, therefore, you wouldn't want to allow more than 3, but of course the answer could be different on other Macs. Perhaps the *important* test is to give control of the number of simultaneous operations back to NSOperationQueue. If that produces elapsed times of about 35, then you have some evidence that the default behavior is the correct choice. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Operations Beachball
What happens if you remove the "isCancelled" checks?
How do you create your operation queue?
What is the max concurrent operation count of the queue? If
NSOperationQueueDefaultMaxConcurrentOperationCount, what happens if you set it
to (processorCount) instead?
When you take a CPU sample of the process, what are your worker threads mainly
doing (work, or being stuck)?
Joar
On 4 dec 2012, at 23:46, Gerriet M. Denkmann wrote:
>
> On 5 Dec 2012, at 01:29, Jens Alfke wrote:
>
>>
>> On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann wrote:
>>
>>> My app creates lots of MyOperations (subclass of NSOperation) and puts them
>>> into an NSOperationQueue.
>>> I would expect that the app thus remains responsive, but sometimes it is
>>> not.
>
>
> I made a test project with this Operation:
>
> @implementation GmdOperationBasis
> - (void)main
> {
> if ( [ self isCancelled ] ) return;
> double sum = 8;
> for( NSUInteger i = 0; i < 13383; i++ )
> {
> if ( [ self isCancelled ] ) return;
> double j = (double)i;
> sum += sqrt(j);
> };
> }
> @end
>
> When I add less than 8 operations to the queue, all is fine.
>
> When I add 8 or more operations to NSOperationQueue (using
> NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) ,
> - then switch to some other app,
> - then try to make my app active again, I get a beach-ball.
>
> My app becomes responsive again, when all operations have finished.
>
> processorCount = 8 (as reported by NSProcessInfo).
>
> 10.8.2. Xcode 4.5.2.
>
>
> Kind regards,
>
> Gerriet.
>
>
>
> ___
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/joar%40joar.com
>
> This email sent to j...@joar.com
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSOperation Efficiency
On 5 Dec 2012, at 15:07, Quincey Morris
wrote:
> On Dec 4, 2012, at 23:02 , "Gerriet M. Denkmann" wrote:
>
>> And got almost the same overhead (tested three times with 99 operations);
>> clock time per operationexpected time overhead factor
>> // 8 ops 29.9, 30.1, 29.712.52.4
>> // 7 ops 29.2, 30.0, 29.714.32.1
>> // 6 ops 28.8, 28.5, 29.016.71.7
>> // 5 ops 28.6, 28.4, 28.920
>> 1.4
>> // 4 ops 29.4, 31.9, 30.825
>> 1.2
>> // 3 ops 35.7, 35.4, 35.233
>> 1.06
>> // 2 ops 51.7, 51.5, 51.250
>> 1.03
>> // 1 ops 100
>>
>> Looks like NSOperationQueue has some problems, or?
>
> Your expected times are questionable:
>
> 1. You "expect" a multi-threaded execution to have no measurable overheads at
> all. Since your expectations are unreasonable, you don't know whether the
> actual times are good or bad.
Well, I expect "some" overhead, like I see for 3 or 4 operations.
> 2. You don't state whether you create all of the operations before letting
> any run, or if you're creating them while some are already running. That's
> going to affect what you measure as overheads. The questions of overheads in
> queuing operations (which Kyle has being saying is inefficient) is an
> entirely separate matter from what you seem to be measuring here.
When I press a button "Start" this gets done:
self.start = [ NSDate date ];
for( NSUInteger i = 0; i < self.nbrWork; i++ )
{
GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
[ self.operationQueue addOperation: m2 ];
};
>
> 4. How many cores on the Mac you used for the test? 2? 4? 8?
No idea. But NSProcessInfo reports: processorCount = 8.
About this Mac says: MacBook Pro; Retina, Mid 2012; Processor 2.3 GHz Intel
Core i7; Memory 8 GB 1600 MHz DDR3.
>
>
> 8. You don't take into account what else might be using CPUs during your
> test.
This is no scientific test. There probably was some 5% CPU time from other
activities.
> Perhaps the *important* test is to give control of the number of simultaneous
> operations back to NSOperationQueue. If that produces elapsed times of about
> 35, then you have some evidence that the default behavior is the correct
> choice.
This I cannot do.
When I use NSOperationQueueDefaultMaxConcurrentOperationCount (i.e. letting
NSOperationQueue decide what is appropriate) then my app will block (see
thread: Operations Beachball).
Kind regards,
Gerriet.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 5 Dec 2012, at 15:57, Joar Wingfors wrote:
> What happens if you remove the "isCancelled" checks?
No effect on blocking.
> How do you create your operation queue?
if ( self.operationQueue == nil )
{
self.operationQueue = [ [ NSOperationQueue alloc ] init ];
#ifdef OBSERVE_OPERATION_COUNT <-- has no effect on blocking
[ self.operationQueue addObserver:self
forKeyPath:
kOperationCount
options:
0
context:
(__bridge void *)kOperationCount
];
#endif
}
else
{
[ self.operationQueue cancelAllOperations ];
};
> What is the max concurrent operation count of the queue? If
> NSOperationQueueDefaultMaxConcurrentOperationCount, what happens if you set
> it to (processorCount) instead?
With (processorCount) it does no longer block. Very strange. This I did not
expect at all.
With NSOperationQueueDefaultMaxConcurrentOperationCount the app gets blocked
with more than 8 operations.
> When you take a CPU sample of the process, what are your worker threads
> mainly doing (work, or being stuck)?
All seem to be in in their main method busy adding square-roots.
>>
>>
>> I made a test project with this Operation:
>>
>> @implementation GmdOperationBasis
>> - (void)main
>> {
>> if ( [ self isCancelled ] ) return;
>> double sum = 8;
>> for( NSUInteger i = 0; i < 13383; i++ )
>> {
>> if ( [ self isCancelled ] ) return;
>> double j = (double)i;
>> sum += sqrt(j);
>> };
>> }
>> @end
>>
>> When I add less than 8 operations to the queue, all is fine.
>>
>> When I add 8 or more operations to NSOperationQueue (using
>> NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) ,
>> - then switch to some other app,
>> - then try to make my app active again, I get a beach-ball.
>>
>> My app becomes responsive again, when all operations have finished.
>>
>> processorCount = 8 (as reported by NSProcessInfo).
>>
>> 10.8.2. Xcode 4.5.2.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSOperation Efficiency
On Dec 5, 2012, at 01:09 , "Gerriet M. Denkmann" wrote:
> When I press a button "Start" this gets done:
>
> self.start = [ NSDate date ];
> for( NSUInteger i = 0; i < self.nbrWork; i++ )
> {
> GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
> [ self.operationQueue addOperation: m2 ];
> };
So operations are being created and queued while some already running, if I
understand correctly. That means your two possible sources of overhead (setup
and concurrency) might well be interacting badly with each other.
> No idea. But NSProcessInfo reports: processorCount = 8.
>
> About this Mac says: MacBook Pro; Retina, Mid 2012; Processor 2.3 GHz Intel
> Core i7; Memory 8 GB 1600 MHz DDR3.
That means you have 4 cores. In that case, it doesn't seem surprising that the
performance increase would be less dramatic after 3-4 threads, since your
operations are intensely compute-bound.
> This I cannot do.
> When I use NSOperationQueueDefaultMaxConcurrentOperationCount (i.e. letting
> NSOperationQueue decide what is appropriate) then my app will block (see
> thread: Operations Beachball).
Yeah, it's a difficult problem.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSOperation Efficiency
On 5 Dec 2012, at 04:41, Kyle Sluder wrote: > NSOperationQueue uses KVO for dependency tracking and queue width > management. In 10.7, the implementation was apparently changed to thunk > all KVO ops onto the main thread; I'm guessing this fixed a bug by > serializing all state changes. It also slowed down enqueueing > operations onto our NSOperationQueue from a background thread by a > factor of ten or more. I have samples to prove it. Wow, that's a big change! Are there are docs to back it up, or is this purely empirical? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 4 Dec 2012, at 18:29, Jens Alfke wrote: > On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann wrote: > >> My app creates lots of MyOperations (subclass of NSOperation) and puts them >> into an NSOperationQueue. >> I would expect that the app thus remains responsive, but sometimes it is not. > > Welcome to the joys of multithreaded programming. :-P You have to be pretty > careful about how you do things, or all sorts of unintuitive and flaky > behaviors can result. > >> + 1343 >> MenuBarInstance::Show(MenuBarAnimationStyle, unsigned char, unsigned char, >> unsigned char) (in HIToolbox) + 625 [0x7fff90ea5063] >> + 1343 BroadcastToolboxMessage (in HIToolbox) + >> 294 [0x7fff90e6e12a] >> + 1343 >> HIS_XPC_CFNotificationCenterPostNotification (in HIServices) + 532 >> [0x7fff8e57f174] >> + 1343 CFNotificationCenterPostNotification >> (in CoreFoundation) + 115 [0x7fff95edbbf3] >> + 1343 _CFXNotificationPost (in >> CoreFoundation) + 1109 [0x7fff95ecced5] >> + 1343 -[_NSDNXPCConnection >> sendMessage:waitForAck:] (in CoreFoundation) + 347 [0x7fff95fec12b] >> + 1343 _dispatch_semaphore_wait_slow >> (in libdispatch.dylib) + 241 [0x7fff97ed0486] >> + 1343 semaphore_wait_trap (in >> libsystem_kernel.dylib) + 10 [0x7fff95ac86c2] >> >> >> I have no idea, what this means. >> Maybe someone can enlighten me. > > The main thread is sending a cross-process (XPC) message and waiting for a > reply. Presumably this has something to do with arbitration of the menu bar > state since the menu bar is a shared resource between apps? But it doesn’t > seem related to anything you’re doing. Is it possible that the XPC that's being waited for here is stalled because whatever's meant to respond to it is a default priority GCD-dispatched block that can't run because GCD has scheduled a lot of your operations, also at the default priority, and won't schedule another (e.g. the one to reply to that message) until the load lightens? I know this sounds unlikely, but it bit me in an iOS project - I was seeing multi-second stalls on the main thread because of this. I 'solved' my problem by lowering the CGD queue priority of my operations. This took care of the large stalls, but to actually get a non-jerky UI, I also had to limit the maxConcurrentOperationCount on my queue to stop GCD from scheduling too many of the operations at once and bogging down the CPU. GCD scheduled too many otherwise because it was fooled into thinking there were resources available whenever a running operation stalled on I/O for a short period. Full details, including samples, are here: https://devforums.apple.com/message/756881. One of the selling points of GCD is that it manages all of this for you, of course, but I've found that's not the case when multiple parts of the system are expecting to be able to use it at once and don't coordinate - especially if there's I/O going on anywhere. Jamie. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSOperation Efficiency
On Tue, Dec 4, 2012, at 08:00 PM, Jens Alfke wrote: > Apologies, but I have trouble believing that. Isn’t NSOperationQueue just > a thin veneer around GCD? By the way, it's worth pointing out that NSOperationQueue is NOT a thin veneer around GCD. Blocks submitted to an NSOperationQueue are dispatched to a common, default-priority concurrent GCD queue. (It might even be the global default concurrent queue.) There is NOT a 1:1 correspondence between NSOperationQueue instances and GCD queues. In order to actually implement the "queue" bit, NSOperationQueue uses KVO. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSOperation Efficiency
On Dec 5, 2012, at 2:05 AM, Mike Abdullah wrote: > > On 5 Dec 2012, at 04:41, Kyle Sluder wrote: > >> NSOperationQueue uses KVO for dependency tracking and queue width >> management. In 10.7, the implementation was apparently changed to thunk >> all KVO ops onto the main thread; I'm guessing this fixed a bug by >> serializing all state changes. It also slowed down enqueueing >> operations onto our NSOperationQueue from a background thread by a >> factor of ten or more. I have samples to prove it. > > Wow, that's a big change! Are there are docs to back it up, or is this purely > empirical? > Not that I've seen. The only evidence I have is a pile of samples. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Cocoaheads Lake Forest meets tonight
CocoaHeads Lake Forest will be meeting on the second Wednesday of the month. We will be meeting at the Orange County Public Library (El Toro) community room, 24672 Raymond Way, Lake Forest, CA 92630 Please join us from 7pm to 9pm on Wednesday, December 5. Stuart Cracraft will be discussing "Massive data mining on a MacBook Air.". Bring laptops, code, discussion topics, etc. As always, details can be found on the cocoaheads web site at www.cocoaheads.org ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoaheads Lake Forest meets tonight
Cancel that. A moment after hitting send, I noted that Dec 5 is NOT the second wednesday of the month. No meeting tonight. Meeting next week. Sorry about the noise. Scott On Wed, Dec 5, 2012 at 9:04 AM, Scott Ellsworth < scott_ellswo...@alumni.hmc.edu> wrote: > CocoaHeads Lake Forest will be meeting on the second Wednesday of the > month. We will be meeting at the Orange County Public Library (El Toro) > community room, 24672 Raymond Way, Lake Forest, CA 92630 > > Please join us from 7pm to 9pm on Wednesday, December 5. > > Stuart Cracraft will be discussing "Massive data mining on a MacBook > Air.". > > Bring laptops, code, discussion topics, etc. > > As always, details can be found on the cocoaheads web site at > www.cocoaheads.org > ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Operations Beachball
On Dec 4, 2012, at 11:46 PM, Gerriet M. Denkmann wrote: > When I add 8 or more operations to NSOperationQueue (using > NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) , > - then switch to some other app, > - then try to make my app active again, I get a beach-ball. > My app becomes responsive again, when all operations have finished. OK, that is nuts, and seems to confirm what Kyle said on one of the many other threads you started: >> NSOperationQueue uses KVO for dependency tracking and queue width >> management. In 10.7, the implementation was apparently changed to thunk all >> KVO ops onto the main thread; I'm guessing this fixed a bug by serializing >> all state changes. It sounds like the large numbers of isCanceled calls your operation is making are somehow causing activity on the main thread that’s blocking other stuff. Very weird. PLEASE take a sample of the app while it’s in the beachballed state and look at what’s going on on the main thread and the GCD threads used by the operation queue. That should give clues about what’s happening. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Object not being drawn in Cmd + N. Why? SOLVED
On Oct 25th 2012 I posted about this. I finally got around to digging into what the cause was and have now got my app working correctly (or at least the way I want it to). In summary it was all related to saving and restoring the graphic context correctly in -drawRect. In my case I use a number of gradients as well a bezier paths and the crucial thing was to understand just where and when to save/restore the context. None of the tools available were of much use, nor was output in the debugger, either console, stack, or variables. It came down to good old-fashioned slicing drawRect till I discovered the cause. So I'm very glad the problem occurred and forced me to research it. I learned a great deal and as the saying goes "K is P". Peter ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Cascading windows
Xcode 4.5.2, Lion 10.7.5 My app is a Document app and I implemented -(void)makeWindowControllers. It could have several documents open at the same time. In particular I want to cascade the window when a New document is opened. I've read up on this and am aware of the NSWindow method - (NSPoint)cascadeTopLeftFromPoint:(NSPoint)topLeft]; // in screen coordinates!! So do I implement the cascading algorithm my WindowController? If so in which method? (a) initWithWindowNibName after the nib is instantiated? (b) windowDidLoad? (c) or somewhere else entirely? Finally I am considering an NSPoint (static?) in my appDelegate to store the last used NSPoint. Does this approach seem correct? If not what would you suggest? I did Google for algorithm and code but nothing helpful popped up. TIA for your comments. Peter ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSOperation Efficiency
On 05/12/2012, at 8:09 PM, Gerriet M. Denkmann wrote:
> for( NSUInteger i = 0; i < self.nbrWork; i++ )
> {
> GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
> [ self.operationQueue addOperation: m2 ];
> };
This is also leaking, could that be affecting your results?
--Graham
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Object not being drawn in Cmd + N. Why? SOLVED
On 06/12/2012, at 5:59 AM, Peter Teeson wrote: > In my case I use a number of gradients as well a bezier paths and the crucial > thing was to understand just where and when to save/restore the context. Well, knowing this is usually a case of common sense. In the vast majority of drawing, you do not need to do this at all, so perhaps you're just doing it "just in case" without fully understanding whether it's really needed. If you overdo it, there is a much bigger likelihood of overdoing it wrong. 1. context save/restores must balance. (if you throw an exception in between, you need to ensure that the restore happens in @finally) 2. you only need to save the context if you make a state change to it that you will want to reverse BEFORE you complete your drawing. 3. Given 2, there are many drawing scenarios where you do not need to save/restore the context at all. 4. I'm pretty sure this is all very well documented in the drawing guide. --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Arc and **
On Dec 4, 2012, at 10:44 PM, Gerriet M. Denkmann wrote: > On 5 Dec 2012, at 12:59, Greg Parker wrote: >> On Dec 4, 2012, at 8:56 PM, Gerriet M. Denkmann wrote: >>> I have (using Arc) a method which works fine: >>> NSString *explanation; >>> [ self doSomeThingAndExplain: &explanation ]; >>> >>> Now I decided that sometimes I don't need this explanation. So I changed it >>> to: >>> >>> NSString **explanatioP = urgent ? NULL : &explanation; // <-- "no explicit >>> ownership... >>> [ self doSomeThingAndExplain: explanatioP]; // passing address of >>> non-local object... >>> >>> But now the compiler gets really upset (errors written as comments above). >>> >>> What Arc-magic is needed to get this to compile? >> >> You need to add explicit ownership to your ** declarations. ARC needs to >> know whether explanationP points to to a strong variable or a weak variable >> or an autoreleasing variable. >> >> This is one way: >> -(void) doSomethingAndExplain:(__strong NSString **)explanationP; >> >> __strong NSString **explanationP = urgent ? NULL : &explanation; >> [self doSomethingAndExplain:explanationP]; >> >> This is another way: >> -(void) doSomethingAndExplain:(NSString **)explanationP; >> // NSString** parameter is implicitly __autoreleasing NSString ** >> >> __autoreleasing NSString **explanationP = urgent ? NULL : &explanation; >> [self doSomethingAndExplain:explanationP]; >> >> The first version may have better performance because it avoids the >> autorelease pool. > > Another way (I don't know how efficient it is though) is: > [self doSomethingAndExplain: urgent ? NULL : &explanation ]; > > Does this use autorelease pool ? Yes. By default, an argument of type id* is assumed to be __autoreleasing id *, because that's the common convention for out-parameters in Cocoa. It is generally more efficient to make your out-parameters __strong id*, but of course that requires a bit more work from MRC callers, which is why it's not the standard convention. John. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cascading windows
The document architecture already provides proper cascading behaviour. What are you seeing that makes you think you need to implement it yourself instead? On 5 Dec 2012, at 20:55, Peter Teeson wrote: > Xcode 4.5.2, Lion 10.7.5 > > My app is a Document app and I implemented -(void)makeWindowControllers. > It could have several documents open at the same time. > In particular I want to cascade the window when a New document is opened. > > I've read up on this and am aware of the NSWindow method > - (NSPoint)cascadeTopLeftFromPoint:(NSPoint)topLeft]; // in screen > coordinates!! > > So do I implement the cascading algorithm my WindowController? If so in which > method? > (a) initWithWindowNibName after the nib is instantiated? > (b) windowDidLoad? > (c) or somewhere else entirely? > > Finally I am considering an NSPoint (static?) in my appDelegate to store the > last used NSPoint. > Does this approach seem correct? If not what would you suggest? > > I did Google for algorithm and code but nothing helpful popped up. > > TIA for your comments. > > Peter > > > > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net > > This email sent to cocoa...@mikeabdullah.net ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to capture a video stream
> On Dec 4, 2012, at 16:50 , gary.gard...@brokensoftware.com wrote: > >> The setSampleBufferDelegate:self queue:queue gives a warning in XCode >> that >> says Sending '' to parameter of incompatible type >> 'id'' > > You need to declare the class of 'self' as conforming to the > AVCaptureVideoDataOutputSampleBufferDelegate protocol. So, for example, if > 'self' is your app delegate, of class MyAppDelegate, then in the header > file instead of this: > > @interface MyAppDelegate : NSObject > > you'd put this: > > @interface MyAppDelegate : NSObject > > > > Do I need to use CoreMedia to actually get an image from the sampleBuffer? Using Xcode, it appears that UIImage is for iOS (this is just a supposition). So XCode changes the code to CIImage. If this is the wrong direction, please point me in the right direction. The AVFoundation examples seem to all be based on IOS and not MAC for the Media Steaming. Therefore those examples don't work for what I am trying to do. I don't want to capture to a file, I just want to get the images from the cam as they are streamed. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to capture a video stream
On Dec 5, 2012, at 19:53 , gary.gard...@brokensoftware.com wrote: > Do I need to use CoreMedia to actually get an image from the sampleBuffer? > Using Xcode, it appears that UIImage is for iOS (this is just a > supposition). So XCode changes the code to CIImage. > > If this is the wrong direction, please point me in the right direction. > > The AVFoundation examples seem to all be based on IOS and not MAC for the > Media Steaming. Therefore those examples don't work for what I am trying > to do. You're correct that the Mac version of the docs haven't been changed from the iOS version, but luckily there is (I think) very little difference you need to take into account. Assuming you have by now got your data capture delegate set up properly, you need to have it do the equivalent of this: https://developer.apple.com/library/mac/#documentation/AudioVideo/Conceptual/AVFoundationPG/Articles/05_MediaRepresentations.html under the final heading "Converting a CMSampleBuffer to a UIImage". In that sample code, you should only have to change one line from its iOS version: UIImage *image = [UIImage imageWithCGImage:cgImage]; to the corresponding Mac version: NSImage *image = [NSImage imageWithCGImage:cgImage]; What happens next depends on what you want to do with the image. If you want to display it, you can simply draw this NSImage object. If you want to write each frame to a separate file, you could use a NSImage method to get the TIFF representation as a NSData object and write that out. If you need to convert the image to a specific form, you will likely have to start creating NSImageRep objects (or a subclass like NSBitmapImageRep), but the details will depend on where you're trying to get to. Note that in some scenarios, you could choose to work with the cgImage directly, rather than creating a NSImage (which is, loosely, just going to function as a wrapper around the CGImage, at least to begin with). The advantage of using NSImage is that it's often less lines of code to use than CGImage (and it's an Objective-C rather than a C API). P.S. The intermediary code uses CVPixelBuffer and CGImage objects, not CIImage objects. CIImage objects are something else entirely -- they're image containers to which image filters can be applied -- that is, they're essentially image transformations. If, for example, you wanted to apply a Gaussian blur to every frame, you could use CIImage objects to do this. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
