Re: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jeff Szuhay]

> On Aug 24, 2016, at 8:02 PM, Britt Durbrow 
>  wrote:
> 
> 
>> On Aug 24, 2016, at 12:59 PM, Jeff Szuhay  wrote:
>> 
>> I draw my images (clocks) into a “reference” sized rectangle—for simplified 
>> position calculations—and then have CoreGraphics scale into the destination 
>> view rect.
> 
> Don’t do that with bitmap scaling. It’s wasteful, and will look bad.
> 
> Instead, create the bitmap at the correct size for it’s destination; and use 
> the drawing matrix transform functions (scale, translate, rotate, etc) to set 
> up your drawing environment.


Okay, so when the user changes the clock size (it’s destination), then recreate 
the bitmap to the new size and redraw everything at the new scale?


___

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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Britt Durbrow]

> On Aug 24, 2016, at 12:59 PM, Jeff Szuhay  wrote:
> 
> I draw my images (clocks) into a “reference” sized rectangle—for simplified 
> position calculations—and then have CoreGraphics scale into the destination 
> view rect.

Don’t do that with bitmap scaling. It’s wasteful, and will look bad.

Instead, create the bitmap at the correct size for it’s destination; and use 
the drawing matrix transform functions (scale, translate, rotate, etc) to set 
up your drawing environment.
___

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: Does setFormatter() retain?

[Graham Cox]

> On 25 Aug 2016, at 6:24 AM, Andreas Falkenhahn  wrote:
> 
> If it retains, I could just do the following:
> 
>[textField setFormatter:formatter];
>[formatter release];
> 
> And I wouldn't have to worry about "formatter" any longer. If it doesn't 
> retain,
> the above isn't possible. 


You should do this anyway - you only need to concern yourself with YOUR memory 
management, not other objects’. Are you done with it? Then release it. Whether 
the other object retained it or not is not your business or concern. If we had 
to know what other objects did with every parameter passed to them programming 
would be impossible.

Or use ARC and let the compiler figure it out.

—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: Does setFormatter() retain?

[Doug Hill]

Also, if you're unsure whether you're following ref-counting rules correctly, 
the static analyzer in Xcode will give very detailed warnings about incorrect 
uses. Just another way to determine if you're using ref-counting correctly.

Doug Hill


> On Aug 24, 2016, at 2:49 PM, Doug Hill  wrote:
> 
> Wim,
> 
> If I may paraphrase:
> 
> The reference counting semantics are only interesting to the caller when the 
> callee returns an object. What the callee does with a setter is entirely the 
> responsibility of the callee to make sure it follows ref-counting rules. For 
> example, a setter may not involve a property or iVar at all, it could be pure 
> side-effects. In terms of ref-counting semantics, the caller doesn't have a 
> clue or need to care what happens
> 
> In this particular case, it would appear that the NSTextField holds a 
> reference the 'formatter' object via the similarly-named property in 
> NSControl. While it might be good to know it's a property so we can make use 
> of property syntax correctly, how it goes about keeping a reference to this 
> object is unimportant to the caller.
> 
> Doug Hill
> 
> PS
> IMHO using manual ref-counting because there is a perceived time-savings from 
> learning ARC is generally a bad argument. The amount of time trying to figure 
> out all the manual ref-counting rules, and making sure your code follows them 
> perfectly, is probably much better spent learning ARC and applying it 
> correctly. And likely results in more maintainable and understandable code. 
> The argument in favor of ARC is especially better if you own the code in 
> question and there isn't much code to write.
> 
> PS #2
> ARC is available in OS X 10.6 as "ARCLite" e.g. "Automatic Reference Counting 
> without zeroing weak reference."
> If you don't require the weak attribute semantics in your own code, then you 
> should be able to use ARC.
> 
> https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/
> 
> 
>> On Aug 24, 2016, at 1:41 PM, Wim Lewis  wrote:
>> 
>> 
>> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn  
>> wrote:
>>> I have read Apple's memory management guide on retain/release and
>>> I think I've basically got it, but there's just one thing that
>>> I'm not confident about and that is "setXXX" methods which accept an
>>> NSObject parameter and I don't know how I can know whether the
>>> "setXXX" retains or not.
>> 
>> In general, if a method you call wants to keep a reference to an object you 
>> pass in, it is that method's responsibility to retain it (or copy it, or 
>> whatever). If it doesn't hold on to the formatter, then it won't retain it. 
>> The goal of reference-counting, whether ARC or not, is that all that 
>> information can be safely considered an implementation detail of the method 
>> you call, and not something you need to worry about.
>> 
>> Delegate and data source setters are an unusual, exceptional case: an object 
>> with a delegate typically doesn't retain its delegate, just keeps a 
>> reference to it. This is dangerous, since the delegate can get deallocated, 
>> leaving a dangling pointer (--> soon you'll crash). If the API conventions 
>> were being formed today, delegates would probably be 'weak' pointers, but 
>> since they predate the existence of weak pointers they get the "slightly 
>> dodgy poor-man's weak pointer" behavior of simply not retaining. Why is 
>> this? It's to avoid retain-cycles, since very often, an object's delegate is 
>> its (direct or indirect) owner in a conceptual sense and therefore already 
>> retains the object.
>> 
>> 
>>> Post-scriptum: Yes, I know, there's now ARC and everything and
>>> all those retain stuff shouldn't be used anymore
>> 
>> ARC just automatically inserts the same retain/release calls that you would 
>> have written manually. (Plus some optimizations on top of that, but that's 
>> the basic idea.) It can be useful to understand MRR even if you don't write 
>> it.
>> 
>> On Aug 24, 2016, at 1:24 PM, Andreas Falkenhahn  
>> wrote:
>>> If it retains, I could just do the following:
>>> 
>>>  [textField setFormatter:formatter];
>>>  [formatter release];
>>> 
>>> And I wouldn't have to worry about "formatter" any longer.
>> 
>> Yes, you can do exactly that. If the textField needs the formatter to 
>> continue to exist after -setFormatter: returns, it will retain it. It's the 
>> textField's job to worry about that retain/release, not yours. You only need 
>> to retain objects that *you* have a reason to reference in the future.
> 
> 
> ___
> 
> 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:
> 

Re: Does setFormatter() retain?

[Doug Hill]

Wim,

If I may paraphrase:

The reference counting semantics are only interesting to the caller when the 
callee returns an object. What the callee does with a setter is entirely the 
responsibility of the callee to make sure it follows ref-counting rules. For 
example, a setter may not involve a property or iVar at all, it could be pure 
side-effects. In terms of ref-counting semantics, the caller doesn't have a 
clue or need to care what happens

In this particular case, it would appear that the NSTextField holds a reference 
the 'formatter' object via the similarly-named property in NSControl. While it 
might be good to know it's a property so we can make use of property syntax 
correctly, how it goes about keeping a reference to this object is unimportant 
to the caller.

Doug Hill

PS
IMHO using manual ref-counting because there is a perceived time-savings from 
learning ARC is generally a bad argument. The amount of time trying to figure 
out all the manual ref-counting rules, and making sure your code follows them 
perfectly, is probably much better spent learning ARC and applying it 
correctly. And likely results in more maintainable and understandable code. The 
argument in favor of ARC is especially better if you own the code in question 
and there isn't much code to write.

PS #2
ARC is available in OS X 10.6 as "ARCLite" e.g. "Automatic Reference Counting 
without zeroing weak reference."
If you don't require the weak attribute semantics in your own code, then you 
should be able to use ARC.

https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/


> On Aug 24, 2016, at 1:41 PM, Wim Lewis  wrote:
> 
> 
> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn  
> wrote:
>> I have read Apple's memory management guide on retain/release and
>> I think I've basically got it, but there's just one thing that
>> I'm not confident about and that is "setXXX" methods which accept an
>> NSObject parameter and I don't know how I can know whether the
>> "setXXX" retains or not.
> 
> In general, if a method you call wants to keep a reference to an object you 
> pass in, it is that method's responsibility to retain it (or copy it, or 
> whatever). If it doesn't hold on to the formatter, then it won't retain it. 
> The goal of reference-counting, whether ARC or not, is that all that 
> information can be safely considered an implementation detail of the method 
> you call, and not something you need to worry about.
> 
> Delegate and data source setters are an unusual, exceptional case: an object 
> with a delegate typically doesn't retain its delegate, just keeps a reference 
> to it. This is dangerous, since the delegate can get deallocated, leaving a 
> dangling pointer (--> soon you'll crash). If the API conventions were being 
> formed today, delegates would probably be 'weak' pointers, but since they 
> predate the existence of weak pointers they get the "slightly dodgy 
> poor-man's weak pointer" behavior of simply not retaining. Why is this? It's 
> to avoid retain-cycles, since very often, an object's delegate is its (direct 
> or indirect) owner in a conceptual sense and therefore already retains the 
> object.
> 
> 
>> Post-scriptum: Yes, I know, there's now ARC and everything and
>> all those retain stuff shouldn't be used anymore
> 
> ARC just automatically inserts the same retain/release calls that you would 
> have written manually. (Plus some optimizations on top of that, but that's 
> the basic idea.) It can be useful to understand MRR even if you don't write 
> it.
> 
> On Aug 24, 2016, at 1:24 PM, Andreas Falkenhahn  
> wrote:
>> If it retains, I could just do the following:
>> 
>>   [textField setFormatter:formatter];
>>   [formatter release];
>> 
>> And I wouldn't have to worry about "formatter" any longer.
> 
> Yes, you can do exactly that. If the textField needs the formatter to 
> continue to exist after -setFormatter: returns, it will retain it. It's the 
> textField's job to worry about that retain/release, not yours. You only need 
> to retain objects that *you* have a reason to reference in the future.


___

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: Does setFormatter() retain?

[Quincey Morris]

On Aug 24, 2016, at 13:37 , Andreas Falkenhahn  wrote:
> 
> Thanks, this would make "setFormatter" a case of strong reference because
> it isn't documented otherwise...

To expand on what Jens said, slightly…

You’d need to check the docs for the version of the SDK you’re using. In a few 
cases, the ownership behavior has changed over time since 10.6. However, it’s 
very difficult to find docs specifically for older SDKs, so look in the SDK 
header files used in your project directly.

If the property is defined via @property, then there’s an API contract about 
ownership (strong, weak, etc). If unspecified, the default is “strong”. There’s 
no ambiguity in this case.

If the property setter is defined as an actual “set…” method, then you can 
assume it retains the value unless there’s a comment saying otherwise. 
___

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: Does setFormatter() retain?

[Wim Lewis]

On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn  wrote:
> I have read Apple's memory management guide on retain/release and
> I think I've basically got it, but there's just one thing that
> I'm not confident about and that is "setXXX" methods which accept an
> NSObject parameter and I don't know how I can know whether the
> "setXXX" retains or not.

In general, if a method you call wants to keep a reference to an object you 
pass in, it is that method's responsibility to retain it (or copy it, or 
whatever). If it doesn't hold on to the formatter, then it won't retain it. The 
goal of reference-counting, whether ARC or not, is that all that information 
can be safely considered an implementation detail of the method you call, and 
not something you need to worry about.

Delegate and data source setters are an unusual, exceptional case: an object 
with a delegate typically doesn't retain its delegate, just keeps a reference 
to it. This is dangerous, since the delegate can get deallocated, leaving a 
dangling pointer (--> soon you'll crash). If the API conventions were being 
formed today, delegates would probably be 'weak' pointers, but since they 
predate the existence of weak pointers they get the "slightly dodgy poor-man's 
weak pointer" behavior of simply not retaining. Why is this? It's to avoid 
retain-cycles, since very often, an object's delegate is its (direct or 
indirect) owner in a conceptual sense and therefore already retains the object.


> Post-scriptum: Yes, I know, there's now ARC and everything and
> all those retain stuff shouldn't be used anymore

ARC just automatically inserts the same retain/release calls that you would 
have written manually. (Plus some optimizations on top of that, but that's the 
basic idea.) It can be useful to understand MRR even if you don't write it.

On Aug 24, 2016, at 1:24 PM, Andreas Falkenhahn  wrote:
> If it retains, I could just do the following:
> 
>[textField setFormatter:formatter];
>[formatter release];
> 
> And I wouldn't have to worry about "formatter" any longer.

Yes, you can do exactly that. If the textField needs the formatter to continue 
to exist after -setFormatter: returns, it will retain it. It's the textField's 
job to worry about that retain/release, not yours. You only need to retain 
objects that *you* have a reason to reference in the future.



___

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: Does setFormatter() retain?

[Ben Kennedy]

> On 24 Aug 2016, at 1:24 pm, Andreas Falkenhahn  wrote:
> 
> If it retains, I could just do the following:
> 
>[textField setFormatter:formatter];
>[formatter release];
> 
> And I wouldn't have to worry about "formatter" any longer. If it doesn't 
> retain,
> the above isn't possible. 

What actually happens inside -setFormatter: is not your concern. Maybe it 
retains the formatter; maybe it just copies some salient details out of it and 
lets it go. It makes no difference to you, the caller.

If you have no further use for the formatter, release it.

> Another example: "addSubview" retains, so I can just do:
> 
>[[win contentView] addSubview:button];
>[button release];
> 
> And I'm done with "button." That's much more convenient than having to
> keep "button" for much longer...

It certainly is. So release it. (The contentView has actually retained the 
button.)

> I still think I should know this so that I know when I should say
> "release" (see above)

You release when you, personally, are done with your object reference.

> So are you saying that the standard for setXXX methods is retain?
> And if a setXXX method doesn't retain, then it's explicitly mentioned
> in the doc?

Not necessarily, no! Maybe, for example, it copies? But it's an implementation 
detail.

If you want to make further reference to an object, you need to retain it in 
order to guarantee its lifecycle. Else, you can trust the API you're calling to 
retain things as it sees fit (unless some documentation advises you otherwise).

There is probably some Apple documentation that expresses the related concerns 
more clearly (or no doubt someone else on the list can be more eloquent). Here 
are a couple, although I recognize they speak more in terms of strong/weak 
references rather than philosophies related to scope of concern and manual 
reference-counting as you're concerned with targeting 10.6:

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html#//apple_ref/doc/uid/TP40011210-CH5-SW3

https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/ObjectOwnership.html#//apple_ref/doc/uid/TP40008195-CH67-SW1

-ben



___

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: Does setFormatter() retain?

[Andreas Falkenhahn]

On 24.08.2016 at 22:25 Jens Alfke wrote:



> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn  
> wrote:

> Now, will "setFormatter" call retain on "formatter" or not? Looking
> at "retainCount" seems to suggest so, although I know that this
> isn't reliable and shouldn't be done at all...



> These days, with ARC, we call those “strong references” vs. “weak” or 
> “unretained” references.


> Strong (retained) references are the default for properties. There
> are a few cases in system frameworks where a property is weak or
> unretained — usually this is used for delegates or data sources, to
> avoid reference cycles that can lead to memory leaks. In this case
> the docs should call out the style of the reference. If there’s no
> mention of it, you can assume it’s strong.

Thanks, this would make "setFormatter" a case of strong reference because
it isn't documented otherwise...

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Does setFormatter() retain?

[Jens Alfke]

> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn  
> wrote:
> 
> Now, will "setFormatter" call retain on "formatter" or not? Looking
> at "retainCount" seems to suggest so, although I know that this
> isn't reliable and shouldn't be done at all...

These days, with ARC, we call those “strong references” vs. “weak” or 
“unretained” references.

Strong (retained) references are the default for properties. There are a few 
cases in system frameworks where a property is weak or unretained — usually 
this is used for delegates or data sources, to avoid reference cycles that can 
lead to memory leaks. In this case the docs should call out the style of the 
reference. If there’s no mention of it, you can assume it’s strong.

—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: Does setFormatter() retain?

[Andreas Falkenhahn]

On 24.08.2016 at 22:14 Ben Kennedy wrote:

>> On 24 Aug 2016, at 1:04 pm, Andreas Falkenhahn  
>> wrote:

>> I have read Apple's memory management guide on retain/release and
>> I think I've basically got it, but there's just one thing that
>> I'm not confident about and that is "setXXX" methods which accept an
>> NSObject parameter and I don't know how I can know whether the
>> "setXXX" retains or not.

> Why do you think you need to know? 

If it retains, I could just do the following:

[textField setFormatter:formatter];
[formatter release];

And I wouldn't have to worry about "formatter" any longer. If it doesn't retain,
the above isn't possible. 

Another example: "addSubview" retains, so I can just do:

[[win contentView] addSubview:button];
[button release];

And I'm done with "button." That's much more convenient than having to
keep "button" for much longer...

> 
> That's the concern of the API
> you're calling. If it needs to retain the object you're passing it,
> then it will. If it doesn't, it won't.

I still think I should know this so that I know when I should say
"release" (see above)

> The legacy delegate stuff that you cited calls out the fact that
> they don't because it is contrary to normal expectations, and thus
> requires explicit concern by the caller.

So are you saying that the standard for setXXX methods is retain?
And if a setXXX method doesn't retain, then it's explicitly mentioned
in the doc?

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jeff Szuhay]

> On Aug 24, 2016, at 12:59 PM, Jeff Szuhay  wrote:
> 
> 
>> On Aug 24, 2016, at 10:37 AM, Jean-Daniel Dupas > > wrote:
>> 
>>> Moreover, the performance will greatly depends the sampling algorithm you 
>>> choose. CGImage provide a couple of algorithms with different tradeoff (see 
>>> CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).
>> 
>> Just for the record, here is a link with different technics available on OS 
>> X to do that: 
>> 
>> http://nshipster.com/image-resizing/ 
> 
> Yeah, but CoreImage is a different kettle of fish.  CoreImage has deprecated 
> the creation of a core image from layers, in favor of bitmaps and 
> static image sources.
> 
> I’m writing an app for Mac OS X/macOS using primarily CoreGraphics and 
> Quartz2D with a smattering of image filters for special effects.
> I draw my images (clocks) into a “reference” sized rectangle—for simplified 
> position calculations—and then have CoreGraphics scale into the destination 
> view rect.
> 
> On my rather old but quite functional 2007 MBP, I notice a considerable 
> difference in CPU use when the clocks are on the laptop main screen (low CPU) 
> versus on a 2nd monitor (high CPU—about 4x). I’ve surmised that the main 
> screen is GPU assisted wheres the 2nd monitor is not. Same clock, just on 
> different screens. I have yet to test whether this will be true on newer 
> MacBookPros with different video cabling/interfaces. 
> 
> I’m in the process of converting my clocks to draw exclusively into offscreen 
> layers (instead of drawing their parts into the device context directly), 
> composing them only when needed, and finally drawing into the view’s graphic 
> context. This, as we’ll soon see, depends upon how efficient the 
> CGContextDrawLayerInRect is when the sour layer and target context are of 
> different sizes—in a single call. 
> 
> Now I’m wondering if an intermediate transformation to scale the layer to the 
> same size as the context and then just call CGContextDrawLayerAtPoint would 
> be more efficient. 
> 
> And, yeah, I’m trying to trade off CPU work for GPU work, and get more work 
> done on the GPU.
> 

Oh, maybe I spoke too soon… Reading the Interpolation section in Programming 
With Quartz
___

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: Does setFormatter() retain?

[Ben Kennedy]

> On 24 Aug 2016, at 1:04 pm, Andreas Falkenhahn  wrote:
> 
> I have read Apple's memory management guide on retain/release and
> I think I've basically got it, but there's just one thing that
> I'm not confident about and that is "setXXX" methods which accept an
> NSObject parameter and I don't know how I can know whether the
> "setXXX" retains or not.

Why do you think you need to know? That's the concern of the API you're 
calling. If it needs to retain the object you're passing it, then it will. If 
it doesn't, it won't.

The legacy delegate stuff that you cited calls out the fact that they don't 
because it is contrary to normal expectations, and thus requires explicit 
concern by the caller.

-ben


___

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

Does setFormatter() retain?

[Andreas Falkenhahn]

I have read Apple's memory management guide on retain/release and
I think I've basically got it, but there's just one thing that
I'm not confident about and that is "setXXX" methods which accept an
NSObject parameter and I don't know how I can know whether the
"setXXX" retains or not.

For example:

I have installed a custom formatter for my NSTextField using

[textField setFormatter:formatter];

Now, will "setFormatter" call retain on "formatter" or not? Looking
at "retainCount" seems to suggest so, although I know that this
isn't reliable and shouldn't be done at all...

So how can I find out if a certain method does a retain or not?
Sometimes, it's explicitly mentioned in the docs, e.g. in NSTableView
for "setDelegate" and "setDataSource" it's explicitly stated that
those methods don't retain. But other methods like "setFormatter"
don't mention anything. Does that mean that they retain then? 

Post-scriptum: Yes, I know, there's now ARC and everything and
all those retain stuff shouldn't be used anymore IIUC but I'm
still targetting 10.6 and my app only has a few lines of Objective C
anyway so it's not too bothering to work with retain.

-- 
Best regards,
 Andreas Falkenhahn  mailto:andr...@falkenhahn.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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jeff Szuhay]

> On Aug 24, 2016, at 10:37 AM, Jean-Daniel Dupas  wrote:
> 
>> Moreover, the performance will greatly depends the sampling algorithm you 
>> choose. CGImage provide a couple of algorithms with different tradeoff (see 
>> CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).
> 
> Just for the record, here is a link with different technics available on OS X 
> to do that: 
> 
> http://nshipster.com/image-resizing/ 

Yeah, but CoreImage is a different kettle of fish.  CoreImage has deprecated 
the creation of a core image from layers, in favor of bitmaps and 
static image sources.

I’m writing an app for Mac OS X/macOS using primarily CoreGraphics and Quartz2D 
with a smattering of image filters for special effects.
I draw my images (clocks) into a “reference” sized rectangle—for simplified 
position calculations—and then have CoreGraphics scale into the destination 
view rect.

On my rather old but quite functional 2007 MBP, I notice a considerable 
difference in CPU use when the clocks are on the laptop main screen (low CPU) 
versus on a 2nd monitor (high CPU—about 4x). I’ve surmised that the main screen 
is GPU assisted wheres the 2nd monitor is not. Same clock, just on different 
screens. I have yet to test whether this will be true on newer MacBookPros with 
different video cabling/interfaces. 

I’m in the process of converting my clocks to draw exclusively into offscreen 
layers (instead of drawing their parts into the device context directly), 
composing them only when needed, and finally drawing into the view’s graphic 
context. This, as we’ll soon see, depends upon how efficient the 
CGContextDrawLayerInRect is when the sour layer and target context are of 
different sizes—in a single call. 

Now I’m wondering if an intermediate transformation to scale the layer to the 
same size as the context and then just call CGContextDrawLayerAtPoint would be 
more efficient. 

And, yeah, I’m trying to trade off CPU work for GPU work, and get more work 
done on the GPU.

___

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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jean-Daniel Dupas]

> Le 24 août 2016 à 19:33, Jean-Daniel Dupas  a écrit :
> 
>> 
>> Le 24 août 2016 à 18:50, David Duncan  a écrit :
>> 
>> 
>>> On Aug 24, 2016, at 1:23 AM, Jeff Szuhay  wrote:
>>> 
>>> I’m using a bunch of layers to draw images to, compose them, and then draw 
>>> into a viewRect
>>> with 
>>> 
>>> CGContextDrawLayerInRect( viewContext, viewRect, myLayer);
>>> 
>>> Of course, I’m trying to pick the most reasonable size for my layers. I 
>>> currently use 1024x1024
>>> but could easily make them 512x512 or 768x768.
>>> 
>>> So my question is, “Is is more efficient to draw the layer into a smaller 
>>> viewRect (down-sample) 
>>> or into a larger ViewRect (up-sample)?” 
>>> 
>>> Or does it even matter?
>> 
>> It depends on if quality or performance matters more.
>> 
>> Downsampling is generally more expensive because you have to deal with more 
>> data and so you become more easily bandwidth limited, but at the same time 
>> if you must resample an image, down sampling generally produces better 
>> quality. Upsampling is the opposite of all that.
>> 
>> So if performance matters more than quality, then you probably want to 
>> upsample.
>> 
> 
> Moreover, the performance will greatly depends the sampling algorithm you 
> choose. CGImage provide a couple of algorithms with different tradeoff (see 
> CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).

Just for the record, here is a link with different technics available on OS X 
to do that: 

http://nshipster.com/image-resizing/


> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: NSAlert::runModal doesn't work on 10.6

[corbin dunn]

> On Aug 23, 2016, at 4:31 PM, dangerwillrobinsondan...@gmail.com wrote:
> 
> 
> 
>> On Aug 24, 2016, at 2:56 AM, Andreas Falkenhahn  
>> wrote:
>> 
>> Is that your personal opinion or is this documented anywhere?
> There's not anything to the contrary I've seen. 

Andreas is right. For you to call NSApplicationMain means you have to have a 
main nib  (or storyboard). But to be clear… NSApplicationMain just initializes 
NSApp (the instance, which is based on NSPrincipalClass), and then calls [NSApp 
run].  The main run loop is in [NSApp run]. You probably can call [NSApp run] 
without actually creating a NIB.

corbin

> Look no further than LSUIElement. 
> There is an info plist key that says you have no UI, and guess what it works 
> even if you included one. 
> There are methods for launching/activating without UI. 
> App templates have evolved over the years. 
> There wasn't always a wired up app delegate in the nib by default. It just 
> happens to be a good starting pattern most of the time. 
> You don't need an app delegate. 
> You don't need a window. 
> You are not required to have any of the default menus. 
> You don't have to provide any icon (the system will provide a default based 
> on the .app bundle UTI). 
> You only really have to have an Info plist but that can be embedded in the 
> binary, so even the app bundle is not required. 
> All this adds up to its not required. It's strongly encouraged and supported 
> because it's a great set of design patterns that facilitate good development 
> and consistent experience within the ecosystem. 
> 
> There are always folks from other language and platform backgrounds who show 
> up wanting to avoid nibs. And they can. But some things are going to be 
> incredibly hard without it. 
> 
> You do need to hang on to that main runloop created by NSApplicationMain() if 
> you want any AppKit views to work right. 
> ___
> 


___

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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jean-Daniel Dupas]

> Le 24 août 2016 à 18:50, David Duncan  a écrit :
> 
> 
>> On Aug 24, 2016, at 1:23 AM, Jeff Szuhay  wrote:
>> 
>> I’m using a bunch of layers to draw images to, compose them, and then draw 
>> into a viewRect
>> with 
>> 
>>  CGContextDrawLayerInRect( viewContext, viewRect, myLayer);
>> 
>> Of course, I’m trying to pick the most reasonable size for my layers. I 
>> currently use 1024x1024
>> but could easily make them 512x512 or 768x768.
>> 
>> So my question is, “Is is more efficient to draw the layer into a smaller 
>> viewRect (down-sample) 
>> or into a larger ViewRect (up-sample)?” 
>> 
>> Or does it even matter?
> 
> It depends on if quality or performance matters more.
> 
> Downsampling is generally more expensive because you have to deal with more 
> data and so you become more easily bandwidth limited, but at the same time if 
> you must resample an image, down sampling generally produces better quality. 
> Upsampling is the opposite of all that.
> 
> So if performance matters more than quality, then you probably want to 
> upsample.
> 

Moreover, the performance will greatly depends the sampling algorithm you 
choose. CGImage provide a couple of algorithms with different tradeoff (see 
CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).


___

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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[David Duncan]

> On Aug 24, 2016, at 1:23 AM, Jeff Szuhay  wrote:
> 
> I’m using a bunch of layers to draw images to, compose them, and then draw 
> into a viewRect
> with 
> 
>   CGContextDrawLayerInRect( viewContext, viewRect, myLayer);
> 
> Of course, I’m trying to pick the most reasonable size for my layers. I 
> currently use 1024x1024
> but could easily make them 512x512 or 768x768.
> 
> So my question is, “Is is more efficient to draw the layer into a smaller 
> viewRect (down-sample) 
> or into a larger ViewRect (up-sample)?” 
> 
> Or does it even matter?

It depends on if quality or performance matters more.

Downsampling is generally more expensive because you have to deal with more 
data and so you become more easily bandwidth limited, but at the same time if 
you must resample an image, down sampling generally produces better quality. 
Upsampling is the opposite of all that.

So if performance matters more than quality, then you probably want to upsample.

> 
> I have an internal goal of using less than 1% of the CPU for my 1 second 
> image drawing so it is
> actually quite important for me to know.
> 
> TIA
> 
> Jeff Szuhay
> a.k.a tickt...@quartertil2.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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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

Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jeff Szuhay]

I’m using a bunch of layers to draw images to, compose them, and then draw into 
a viewRect
with 

CGContextDrawLayerInRect( viewContext, viewRect, myLayer);

Of course, I’m trying to pick the most reasonable size for my layers. I 
currently use 1024x1024
but could easily make them 512x512 or 768x768.

So my question is, “Is is more efficient to draw the layer into a smaller 
viewRect (down-sample) 
or into a larger ViewRect (up-sample)?” 

Or does it even matter?

I have an internal goal of using less than 1% of the CPU for my 1 second image 
drawing so it is
actually quite important for me to know.

TIA

Jeff Szuhay
a.k.a tickt...@quartertil2.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