Re: NSImage to JPEG file?

[Alastair Houghton]

On 16 Jan 2019, at 20:17, Jens Alfke  wrote:
> 
>> On Jan 16, 2019, at 9:59 AM, Carl Hoefs  
>> wrote:
>> 
>> But all of that would come "for free" if NSImage inherited from NSData, no?
> 
> Well, that wouldn’t make sense, because an NSImage isn’t a piece of data. It 
> can have multiple data representations (JPEG, PNG, PDF…) and it might not 
> have any at all if it was created directly in-memory with a pixmap. It’s a 
> thing that can create a data representation.

Quite.  This point is worth emphasising, actually.  A very common mistake 
people make when trying to write OO programs is using inheritance where there 
isn’t an is-a relationship.

NSImage definitely *is not* an NSData, and so should not inherit from it.

(Indeed, it could even have a custom NSImageRep backing it that does the 
drawing on the fly; indeed, there is actually a built-in version of this in the 
current version of Cocoa, where you can specify a block that gets used to 
render the image whenever the system feels it’s necessary.)

This confusion isn’t helped by the fact that certain commonly used OO languages 
(I’m looking at you, C++) muddy the waters by trying to use inheritance for 
multiple different purposes (e.g. interfaces, typically via pure virtual 
classes; mixins and the like for *implementation* purposes - which largely only 
works because of multiple inheritance and/or templates, depending on how the 
mixin is built).

Kind regards,

Alastair.

--
http://alastairs-place.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: NSImage to JPEG file?

[Jens Alfke]

> On Jan 16, 2019, at 9:59 AM, Carl Hoefs  
> wrote:
> 
> But all of that would come "for free" if NSImage inherited from NSData, no?

Well, that wouldn’t make sense, because an NSImage isn’t a piece of data. It 
can have multiple data representations (JPEG, PNG, PDF…) and it might not have 
any at all if it was created directly in-memory with a pixmap. It’s a thing 
that can create a data representation.

—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

NSImage to JPEG file?

[Greg Weston]

>> That would be poor API design. If it had -writeToFile, then it would also 
>> need -writeToStream:, -writeToFileHandle:, -writeToFileDescriptor:, 
>> -writeToNSURLSessionDataDelegate:, etc.
>> Providing the data itself means you can then use existing APIs on other 
>> classes to put the data anywhere you want.
> 
> But all of that would come "for free" if NSImage inherited from NSData, no?

No. Because there’s no guarantee that the “data” that define an NSImage - or 
its representation(s) - conform to any specific commodity format.
___

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: NSImage to JPEG file?

[Carl Hoefs]

> On Jan 16, 2019, at 10:43 AM, Jens Alfke  wrote:
> 
>> On Jan 16, 2019, at 8:32 AM, Carl Hoefs > <mailto:newsli...@autonomy.caltech.edu>> wrote:
>> 
>> It was the NSData tie-in I didn't know. (I was expecting NSImage to have 
>> innate export capabilities
> 
> That would be poor API design. If it had -writeToFile, then it would also 
> need -writeToStream:, -writeToFileHandle:, -writeToFileDescriptor:, 
> -writeToNSURLSessionDataDelegate:, etc.
> Providing the data itself means you can then use existing APIs on other 
> classes to put the data anywhere you want.

But all of that would come "for free" if NSImage inherited from NSData, no?

-Carl


___

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: NSImage to JPEG file?

[Jens Alfke]

> On Jan 16, 2019, at 8:32 AM, Carl Hoefs  
> wrote:
> 
> It was the NSData tie-in I didn't know. (I was expecting NSImage to have 
> innate export capabilities

That would be poor API design. If it had -writeToFile, then it would also need 
-writeToStream:, -writeToFileHandle:, -writeToFileDescriptor:, 
-writeToNSURLSessionDataDelegate:, etc.
Providing the data itself means you can then use existing APIs on other classes 
to put the data anywhere you want.

—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: NSImage to JPEG file?

[Carl Hoefs]

Thanks Wim and Gerd. It was the NSData tie-in I didn't know. (I was expecting 
NSImage to have innate export capabilities, but this works too.)

-Carl


> On Jan 16, 2019, at 7:56 AM, Wim Lewis  wrote:
> 
> On Tue, Jan 15, 2019 at 08:10:58PM -0700, Carl Hoefs wrote:
>> Using NSBitmapImageRep, is it possible to write the JPEG representation out 
>> to a .JPG file on disk?
> 
> The normal way is to get the JPEG representation as a NSData and then 
> write that NSData to disk using (e.g.) -writeToFile:options:error:.
> 
> The ImageIO functions allow you to stream the data to disk (instead of 
> creating a complete representation in memory before writing), which can 
> be more efficient, but in my experience this is rarely a concern.
> 

___

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: NSImage to JPEG file?

[Carl Hoefs]

Using NSBitmapImageRep, is it possible to write the JPEG representation out to 
a .JPG file on disk?

-Carl

> On Jan 15, 2019, at 4:01 PM, Jens Alfke  wrote:
> 
> It’s been a long time since I worked with NSImages, but it’s easy to get a 
> JPEG representation using just plain AppKit. 
> 
> Just look through the representations for an NSBitmapImageRep, then call [rep 
> representationUsingType: NSBitmapImageFileTypeJPEG options: 0].
> 
> —Jens
> 
> PS: _Please_ don’t reply to digests. It messes up the subject line and the 
> message threading.
> ___
> 
> 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/newslists%40autonomy.caltech.edu
> 
> This email sent to newsli...@autonomy.caltech.edu

___

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: NSImage to JPEG file?

[Jens Alfke]

It’s been a long time since I worked with NSImages, but it’s easy to get a JPEG 
representation using just plain AppKit. 

Just look through the representations for an NSBitmapImageRep, then call [rep 
representationUsingType: NSBitmapImageFileTypeJPEG options: 0].

—Jens

PS: _Please_ don’t reply to digests. It messes up the subject line and the 
message threading.
___

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: NSImage to JPEG file?

[Alex Zavatone]

I will send you something.

Sent from my iPhone

> On Jan 14, 2019, at 2:17 PM, Carl Hoefs  
> wrote:
> 
> I have a background macOS daemon process (aka Foundation-based "command line 
> tool") that needs to write out a JPEG file to local disk. The image resides 
> in an NSImage object (or alternatively, an NSData of raw RGB image data). 
> 
> Short of resorting to something like libjpeg, what is the ObjC way to do this?
> 
> -Carl
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.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: NSImage to JPEG file?

[Carl Hoefs]

Got it working!
Thanks, that's the tip I needed. 
-Carl


> On Jan 14, 2019, at 1:26 PM, Vince DeMarco  wrote:
> 
> Use ImageIO.
> 
> create a CGImageDestinationRef and add the CGImage to it.
> 
> Vince
> 
> 
> 
>> On Jan 14, 2019, at 12:17 PM, Carl Hoefs  
>> wrote:
>> 
>> I have a background macOS daemon process (aka Foundation-based "command line 
>> tool") that needs to write out a JPEG file to local disk. The image resides 
>> in an NSImage object (or alternatively, an NSData of raw RGB image data). 
>> 
>> Short of resorting to something like libjpeg, what is the ObjC way to do 
>> this?
>> 
>> -Carl
>> 
>> ___
>> 
>> 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/demarco%40apple.com
>> 
>> This email sent to dema...@apple.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: NSImage to JPEG file?

[Vince DeMarco]

Use ImageIO.

create a CGImageDestinationRef and add the CGImage to it.

Vince



> On Jan 14, 2019, at 12:17 PM, Carl Hoefs  
> wrote:
> 
> I have a background macOS daemon process (aka Foundation-based "command line 
> tool") that needs to write out a JPEG file to local disk. The image resides 
> in an NSImage object (or alternatively, an NSData of raw RGB image data). 
> 
> Short of resorting to something like libjpeg, what is the ObjC way to do this?
> 
> -Carl
> 
> ___
> 
> 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/demarco%40apple.com
> 
> This email sent to dema...@apple.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

NSImage to JPEG file?

[Carl Hoefs]

I have a background macOS daemon process (aka Foundation-based "command line 
tool") that needs to write out a JPEG file to local disk. The image resides in 
an NSImage object (or alternatively, an NSData of raw RGB image data). 

Short of resorting to something like libjpeg, what is the ObjC way to do this?

-Carl

___

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: Pasteboard and NSImage and Finder

[Rob Petrovec]

Nope.  Pasteboard does not support ‘promised' data like drags do.  Sorry.  You 
could write them to a temporary folder (e.g. NSTemporaryDirectory()) and then 
stuff the URLs on the pasteboard.

—Rob


> On Apr 10, 2018, at 12:44 PM, Daniel Santos <daniel.d...@gmail.com> wrote:
> 
> That thought crossed my mind. I don’t want to write the file to disk, just 
> have a NSFile object in memory, is that possible ?
> 
> Daniel
> 
>> On 9 Apr 2018, at 23:25, Rob Petrovec <petr...@mac.com> wrote:
>> 
>> You need to put files on the pasteboard.  Finder only plays with files, not 
>> raw image data.
>> 
>> —Rob
>> 
>> 
>>> On Apr 9, 2018, at 4:12 PM, Daniel Santos <daniel.d...@gmail.com> wrote:
>>> 
>>> Hello all,
>>> 
>>> I am pasting an array of NSImage to the general pasteboard. (using 
>>> pasteboard .writeObjects())
>>> I would like to be able to paste the images onto Finder. What do I need to 
>>> do ?
>>> 
>>> Thanks in advance
>>> ___
>>> 
>>> 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/petrock%40mac.com
>>> 
>>> This email sent to petr...@mac.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: Pasteboard and NSImage and Finder

[Daniel Santos]

That thought crossed my mind. I don’t want to write the file to disk, just have 
a NSFile object in memory, is that possible ?

Daniel

> On 9 Apr 2018, at 23:25, Rob Petrovec <petr...@mac.com> wrote:
> 
> You need to put files on the pasteboard.  Finder only plays with files, not 
> raw image data.
> 
> —Rob
> 
> 
>> On Apr 9, 2018, at 4:12 PM, Daniel Santos <daniel.d...@gmail.com> wrote:
>> 
>> Hello all,
>> 
>> I am pasting an array of NSImage to the general pasteboard. (using 
>> pasteboard .writeObjects())
>> I would like to be able to paste the images onto Finder. What do I need to 
>> do ?
>> 
>> Thanks in advance
>> ___
>> 
>> 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/petrock%40mac.com
>> 
>> This email sent to petr...@mac.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: Pasteboard and NSImage and Finder

[Rob Petrovec]

You need to put files on the pasteboard.  Finder only plays with files, not raw 
image data.

—Rob


> On Apr 9, 2018, at 4:12 PM, Daniel Santos <daniel.d...@gmail.com> wrote:
> 
> Hello all,
> 
> I am pasting an array of NSImage to the general pasteboard. (using pasteboard 
> .writeObjects())
> I would like to be able to paste the images onto Finder. What do I need to do 
> ?
> 
> Thanks in advance
> ___
> 
> 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/petrock%40mac.com
> 
> This email sent to petr...@mac.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

Pasteboard and NSImage and Finder

[Daniel Santos]

Hello all,

I am pasting an array of NSImage to the general pasteboard. (using pasteboard 
.writeObjects())
I would like to be able to paste the images onto Finder. What do I need to do ?

Thanks in advance
___

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: Writing NSImage

[Graham Cox]

Drop down one level - create a bitmap image rep of the type you want, make a 
context for it, draw the image into that, then (if necessary) add it to a 
NSImage with addRepresentation:

Working at this level you have total control, and rarely need an NSImage at all.

—Graham




> On 21 Jun 2017, at 4:10 pm, Gerriet M. Denkmann <gerri...@icloud.com> wrote:
> 
> macOS 12.5
> 
> I create an image like:
> 
> NSImage *subImage = [ [NSImage alloc] initWithSize: subRect.size ];
> [ subImage lockFocus ];
> [ self.image  drawAtPoint:NSMakePoint(0, 0)  
>   fromRect:   subRect  
>   operation:  
> NSCompositingOperationCopy  
>   fraction:   1 
> ];
> [ subImage unlockFocus ];
> 
> My NSImageView has no problem showing subImage. So far so good.
> 
> But now I try to write it like:
> NSArray *representations = subImage.representations;  //  contains 1 rep
> NSBitmapImageRep *oneRep = representations.firstObject;   
> 
> The problem is: oneRep is an NSCGImageSnapshotRep, which does NOT understand 
>   [ NSBitmapImageRep  representationUsingType:properties: ].
> (It crashes with a message to this effect).
> 
> So: how can I provide my subImage with a nice and valid NSBitmapImageRep?
> 
> Btw.: subImage.TIFFRepresentation does work, but I am not really interested 
> in Tiff.
> 
> 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/graham.cox%40bigpond.com
> 
> This email sent to graham@bigpond.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

Writing NSImage

[Gerriet M. Denkmann]

macOS 12.5

I create an image like:

NSImage *subImage = [ [NSImage alloc] initWithSize: subRect.size ];
[ subImage lockFocus ];
[ self.imagedrawAtPoint:NSMakePoint(0, 0)  
fromRect:   subRect  
operation:  
NSCompositingOperationCopy  
fraction:   1 
];
[ subImage unlockFocus ];

My NSImageView has no problem showing subImage. So far so good.

But now I try to write it like:
NSArray *representations = subImage.representations;//  contains 1 rep
NSBitmapImageRep *oneRep = representations.firstObject; 

The problem is: oneRep is an NSCGImageSnapshotRep, which does NOT understand 
[ NSBitmapImageRep  representationUsingType:properties: ].
(It crashes with a message to this effect).

So: how can I provide my subImage with a nice and valid NSBitmapImageRep?

Btw.: subImage.TIFFRepresentation does work, but I am not really interested in 
Tiff.

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: NSImage drawInRect deadlock

[Doug Hill]

> On Aug 10, 2016, at 4:49 PM, Graham Cox  wrote:
> 
> 
>> On 9 Aug 2016, at 4:05 AM, Andrew Keller  wrote:
>> 
>> In my app, I’m creating thumbnails of images.  To do this in parallel, I’m 
>> using the global background dispatch queue:
> 
> 
> Just to throw another consideration into the discusion, you don’t say what 
> the thumbnails are being used for.
> 
> Typically you might want to display these to the user to browse a collection 
> of images. If that’s the case here, then it might be much more performant to 
> create them only as needed for display, rather than generate a huge batch of 
> them ahead of time. In other words, when an image thumbnail is required *for 
> display*, kick off a thread to fetch it (or display the one you have cached 
> already). This means that first time the user scrolls through the collection, 
> thumbnails will ‘pop in’ to view as each thread completes, but this effect is 
> usually easily tolerated. With scroll pre-fetching you might not even see it 
> at all.
> 
> This way your threads are naturally limited by the number of images that are 
> shown at a time, or scrolled newly into view.
> 
> —Graham

+1
___

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: NSImage drawInRect deadlock

[Graham Cox]

> On 9 Aug 2016, at 4:05 AM, Andrew Keller  wrote:
> 
> In my app, I’m creating thumbnails of images.  To do this in parallel, I’m 
> using the global background dispatch queue:


Just to throw another consideration into the discusion, you don’t say what the 
thumbnails are being used for.

Typically you might want to display these to the user to browse a collection of 
images. If that’s the case here, then it might be much more performant to 
create them only as needed for display, rather than generate a huge batch of 
them ahead of time. In other words, when an image thumbnail is required *for 
display*, kick off a thread to fetch it (or display the one you have cached 
already). This means that first time the user scrolls through the collection, 
thumbnails will ‘pop in’ to view as each thread completes, but this effect is 
usually easily tolerated. With scroll pre-fetching you might not even see it at 
all.

This way your threads are naturally limited by the number of images that are 
shown at a time, or scrolled newly into view.

—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: NSImage drawInRect deadlock

[Andrew Keller]

Am 10.08.2016 um 2:48 vorm. schrieb Quincey Morris 
<quinceymor...@rivergatesoftware.com>:
> On Aug 9, 2016, at 20:47 , Andrew Keller <and...@kellerfarm.com 
> <mailto:and...@kellerfarm.com>> wrote:
>> 
>> 2. When utilizing Mike’s approach to limiting the number of parallel tasks 
>> down to, say, 1-8, I have been completely unable to reproduce the deadlock.
>> 3. When utilizing Mike’s approach to limiting the number of parallel tasks, 
>> Xcode is still saying that threads a being created like crazy — almost one 
>> thread per block submitted to the queue.
> 
> I’m not a big fan of Mike’s proposed solution. If you want to use N-wide 
> parallelism, then use NSOperationQueue, not GCD.
> 
> Blocks dispatched to GCD queues should not contain any internal waits, such 
> as for I/O. Instead, a dispatched block should occupy the CPU continuously, 
> and at the end do one of 3 things:
> 
> 1. Just exit.
> 
> 2. Start an asynchronous action, such as GCD I/O, with a completion handler 
> that’s not scheduled until the action is done.
> 
> 3. Queue another block that represents another processing step in the overall 
> task being performed.
> 
> The point of #3 is that I think it’s also a mistake to queue large numbers of 
> blocks to GCD all at once, for the pragmatic reason that if you accidentally 
> violate the non-internal-waits rule, the size of the thread explosion depends 
> on the amount of combustible material that’s queued. It’s better for *each 
> operation* to queue its successor, and to start the whole thing off by 
> priming the pump with a modest number of blocks.
> 
> The other thing to be very careful of is global locks. If your code (perhaps 
> outside your direct control) hits any global locks that affect multiple 
> threads, *and* if the kind of lock being used is slower to test when locked 
> than when unlocked, then more parallelism can be counterproductive.
> 
> I’ve run into this in cases where adding more operations on more CPUs just 
> adds a disproportionate amount of system overhead, decreasing the throughput 
> of the actual calculation.
> 
> The point of all this is that you may not have enough control of the internal 
> behavior of those NSImage methods to safely use GCD parallelism for a job 
> like this. NSOperationQueue might be a better solution.

Interesting idea.  I’ve modified my scheduler to use existing work to post the 
next work to GCD.  This implementation has no semaphores and no custom dispatch 
queues at all.  Interestingly, I get roughly the same results: no crazy 
swapping to disk, no deadlock, and Xcode is still saying that threads are 
piling up like crazy.  (Note that I’m not letting the concurrent procedure 
count past 8)

That said, this implementation does “feel” better than before from an 
architectural point of view.  I believe I have more along the lines of 
“computationally intensive things I can do to iteratively improve the UI” 
rather than “a long list of work to do”.  Based on what the user is doing, I 
can prioritize certain parts of the UI being rendered before others, and using 
existing work to post the next work in GCD makes a lot of sense because the 
concept of “future work” can change so easily.  I know NSOperationQueue 
supports giving certain tasks priority, but I’d have to actually set all of 
those values — whereas with blocks posting other blocks, I get this behavior 
almost for free because there is always “the next most useful thing to render 
in the UI”.  If some distant future work happens to become irreverent because 
the user moved to another screen, then this approach simply never gets around 
to queueing that work, which is usually good.

Thanks,
 - Andrew

___

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: NSImage drawInRect deadlock

[Quincey Morris]

On Aug 9, 2016, at 20:47 , Andrew Keller <and...@kellerfarm.com> wrote:
> 
> 2. When utilizing Mike’s approach to limiting the number of parallel tasks 
> down to, say, 1-8, I have been completely unable to reproduce the deadlock.
> 3. When utilizing Mike’s approach to limiting the number of parallel tasks, 
> Xcode is still saying that threads a being created like crazy — almost one 
> thread per block submitted to the queue.

I’m not a big fan of Mike’s proposed solution. If you want to use N-wide 
parallelism, then use NSOperationQueue, not GCD.

Blocks dispatched to GCD queues should not contain any internal waits, such as 
for I/O. Instead, a dispatched block should occupy the CPU continuously, and at 
the end do one of 3 things:

1. Just exit.

2. Start an asynchronous action, such as GCD I/O, with a completion handler 
that’s not scheduled until the action is done.

3. Queue another block that represents another processing step in the overall 
task being performed.

The point of #3 is that I think it’s also a mistake to queue large numbers of 
blocks to GCD all at once, for the pragmatic reason that if you accidentally 
violate the non-internal-waits rule, the size of the thread explosion depends 
on the amount of combustible material that’s queued. It’s better for *each 
operation* to queue its successor, and to start the whole thing off by priming 
the pump with a modest number of blocks.

The other thing to be very careful of is global locks. If your code (perhaps 
outside your direct control) hits any global locks that affect multiple 
threads, *and* if the kind of lock being used is slower to test when locked 
than when unlocked, then more parallelism can be counterproductive.

I’ve run into this in cases where adding more operations on more CPUs just adds 
a disproportionate amount of system overhead, decreasing the throughput of the 
actual calculation.

The point of all this is that you may not have enough control of the internal 
behavior of those NSImage methods to safely use GCD parallelism for a job like 
this. NSOperationQueue might be a better solution.

___

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: NSImage drawInRect deadlock

[Andrew Keller]

Am 09.08.2016 um 7:38 nachm. schrieb Andrew Keller :
> Am 09.08.2016 um 3:59 nachm. schrieb Kyle Sluder :
>> On Tue, Aug 9, 2016, at 07:38 AM, Andrew Keller wrote:
>> 
>>> I was under the impression from the docs that macOS
>>> handles the thread pool “automatically”.
>> 
>> Mike Ash did a good job explaining why this isn’t as “automatic” as one
>> might think:
>> https://www.mikeash.com/pyblog/friday-qa-2009-09-25-gcd-practicum.html 
>> 
> 
> Wow.  That was incredibly eye opening.  I’m seeing the exact same symptoms 
> he’s describing — the deadlock is just the sugar on top.
> 
> I’m going to play with some of his concepts and see what happens.  I wonder 
> if the deadlock can be worked around by using the image scaling approach he 
> uses in his example.

A few interesting observations:

1. Mike’s thumbnail generation process is vulnerable to the same deadlock as my 
code.  In hindsight, this is not surprising since we are both using drawInRect.
2. When utilizing Mike’s approach to limiting the number of parallel tasks down 
to, say, 1-8, I have been completely unable to reproduce the deadlock.
3. When utilizing Mike’s approach to limiting the number of parallel tasks, 
Xcode is still saying that threads a being created like crazy — almost one 
thread per block submitted to the queue.

#2 suggests that this deadlock issue is related to very large (20+?  30+?  40+? 
 100+?) numbers of threads operating at the same time.

Not sure what to do about #3.  So long as it doesn’t negatively impact the app, 
I suppose I could ignore it for now.  (Unless anyone has seen this behavior, 
and perhaps foresees a problem with it.)

Thanks,
 - Andrew


___

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: NSImage drawInRect deadlock

[Andrew Keller]

Am 09.08.2016 um 3:59 nachm. schrieb Kyle Sluder :
> On Tue, Aug 9, 2016, at 07:38 AM, Andrew Keller wrote:
> 
>> I was under the impression from the docs that macOS
>> handles the thread pool “automatically”.
> 
> Mike Ash did a good job explaining why this isn’t as “automatic” as one
> might think:
> https://www.mikeash.com/pyblog/friday-qa-2009-09-25-gcd-practicum.html 
> 

Wow.  That was incredibly eye opening.  I’m seeing the exact same symptoms he’s 
describing — the deadlock is just the sugar on top.

I’m going to play with some of his concepts and see what happens.  I wonder if 
the deadlock can be worked around by using the image scaling approach he uses 
in his example.

Thanks,
 - Andrew

___

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: NSImage drawInRect deadlock

[Jens Alfke]

>> I was under the impression from the docs that macOS
>> handles the thread pool “automatically”.

GCD’s pool does use a thread per CPU core … but only as long as none of the 
operations run for a long time. If its entire thread pool is busy for “a while” 
and there are more blocks waiting in the queue, GCD will start to create more 
threads to keep up, rather than let the waiting threads starve.

—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: NSImage drawInRect deadlock

[Kyle Sluder]

On Tue, Aug 9, 2016, at 07:38 AM, Andrew Keller wrote:
> Am 08.08.2016 um 8:12 nachm. schrieb Kyle Sluder <k...@ksluder.com>:
> > 
> > On Mon, Aug 8, 2016, at 05:11 PM, Jens Alfke wrote:
> >> 
> >>> On Aug 8, 2016, at 2:54 PM, Aaron Tuller <mandelb...@mac.com> wrote:
> >>> 
> >>> "The following classes and functions are generally not thread-safe. In 
> >>> most cases, you can use these classes from any thread as long as you use 
> >>> them from only one thread at a time."
> >> 
> >> The images are only being used on one thread at a time. The problem seems
> >> to be that the NSImage _cache_ is shared and (apparently) not
> >> thread-safe.
> > 
> > I wouldn’t jump immediately to thread-unsafety. It’s possible that
> > Andrew is simply exhausting the thread pool.
> > 
> > Andrew, are you doing anything to limit the amount of decode operations
> > you’re putting on the global queue?
> 
> Not presently.  Under normal usage, it hovers around 10-40 threads, but
> I’ve seen it as high as 200.  Honestly, I was hoping to limit it to 3 or
> 6 — just experimentally, one thread by itself can saturate roughly 20-30%
> of my i7 processor.  If 3-6 simultaneous operations will saturate the
> whole processor, I don’t see much value in letting it go much higher than
> that.
> 
> What is the preferred way to limit the number of parallel operations in
> the global queue?  I was under the impression from the docs that macOS
> handles the thread pool “automatically”.

Mike Ash did a good job explaining why this isn’t as “automatic” as one
might think:
https://www.mikeash.com/pyblog/friday-qa-2009-09-25-gcd-practicum.html

--Kyle Sluder

> 
> Thanks,
>  - Andrew
> 

___

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: NSImage drawInRect deadlock

[Damien DeVille]

You could change your code to use `NSBlockOperation`. You would then
have an `NSOperationQueue` on which you could set the
`maxConcurrentOperationCount` to whatever number makes sense for you.

Damien

On Tue, Aug 9, 2016, at 05:38 AM, Andrew Keller wrote:
> Am 08.08.2016 um 8:12 nachm. schrieb Kyle Sluder <k...@ksluder.com>:
> > 
> > On Mon, Aug 8, 2016, at 05:11 PM, Jens Alfke wrote:
> >> 
> >>> On Aug 8, 2016, at 2:54 PM, Aaron Tuller <mandelb...@mac.com> wrote:
> >>> 
> >>> "The following classes and functions are generally not thread-safe. In 
> >>> most cases, you can use these classes from any thread as long as you use 
> >>> them from only one thread at a time."
> >> 
> >> The images are only being used on one thread at a time. The problem seems
> >> to be that the NSImage _cache_ is shared and (apparently) not
> >> thread-safe.
> > 
> > I wouldn’t jump immediately to thread-unsafety. It’s possible that
> > Andrew is simply exhausting the thread pool.
> > 
> > Andrew, are you doing anything to limit the amount of decode operations
> > you’re putting on the global queue?
> 
> Not presently.  Under normal usage, it hovers around 10-40 threads, but
> I’ve seen it as high as 200.  Honestly, I was hoping to limit it to 3 or
> 6 — just experimentally, one thread by itself can saturate roughly 20-30%
> of my i7 processor.  If 3-6 simultaneous operations will saturate the
> whole processor, I don’t see much value in letting it go much higher than
> that.
> 
> What is the preferred way to limit the number of parallel operations in
> the global queue?  I was under the impression from the docs that macOS
> handles the thread pool “automatically”.
> 
> Thanks,
>  - Andrew
> 
> 
> ___
> 
> 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/damien%40ddeville.me
> 
> This email sent to dam...@ddeville.me

___

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: NSImage drawInRect deadlock

[Andrew Keller]

Am 08.08.2016 um 8:12 nachm. schrieb Kyle Sluder <k...@ksluder.com>:
> 
> On Mon, Aug 8, 2016, at 05:11 PM, Jens Alfke wrote:
>> 
>>> On Aug 8, 2016, at 2:54 PM, Aaron Tuller <mandelb...@mac.com> wrote:
>>> 
>>> "The following classes and functions are generally not thread-safe. In most 
>>> cases, you can use these classes from any thread as long as you use them 
>>> from only one thread at a time."
>> 
>> The images are only being used on one thread at a time. The problem seems
>> to be that the NSImage _cache_ is shared and (apparently) not
>> thread-safe.
> 
> I wouldn’t jump immediately to thread-unsafety. It’s possible that
> Andrew is simply exhausting the thread pool.
> 
> Andrew, are you doing anything to limit the amount of decode operations
> you’re putting on the global queue?

Not presently.  Under normal usage, it hovers around 10-40 threads, but I’ve 
seen it as high as 200.  Honestly, I was hoping to limit it to 3 or 6 — just 
experimentally, one thread by itself can saturate roughly 20-30% of my i7 
processor.  If 3-6 simultaneous operations will saturate the whole processor, I 
don’t see much value in letting it go much higher than that.

What is the preferred way to limit the number of parallel operations in the 
global queue?  I was under the impression from the docs that macOS handles the 
thread pool “automatically”.

Thanks,
 - Andrew


___

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: NSImage drawInRect deadlock

[Kyle Sluder]

On Mon, Aug 8, 2016, at 05:11 PM, Jens Alfke wrote:
> 
> > On Aug 8, 2016, at 2:54 PM, Aaron Tuller <mandelb...@mac.com> wrote:
> > 
> > "The following classes and functions are generally not thread-safe. In most 
> > cases, you can use these classes from any thread as long as you use them 
> > from only one thread at a time."
> 
> The images are only being used on one thread at a time. The problem seems
> to be that the NSImage _cache_ is shared and (apparently) not
> thread-safe.

I wouldn’t jump immediately to thread-unsafety. It’s possible that
Andrew is simply exhausting the thread pool.

Andrew, are you doing anything to limit the amount of decode operations
you’re putting on the global queue?

--Kyle

> 
> —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: NSImage drawInRect deadlock

[Jens Alfke]

> On Aug 8, 2016, at 2:54 PM, Aaron Tuller <mandelb...@mac.com> wrote:
> 
> "The following classes and functions are generally not thread-safe. In most 
> cases, you can use these classes from any thread as long as you use them from 
> only one thread at a time."

The images are only being used on one thread at a time. The problem seems to be 
that the NSImage _cache_ is shared and (apparently) not thread-safe.

—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: NSImage drawInRect deadlock

[Aaron Tuller]

On Aug 8, 2016, at 1:48 PM, Jens Alfke <j...@mooseyard.com> wrote:
> On Aug 8, 2016, at 12:46 PM, Aaron Tuller <mandelb...@mac.com 
> <mailto:mandelb...@mac.com>> wrote:
>> 
>> Search for NSImage here:
>> 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/1057i-CH12-126728
>>  
>> <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/1057i-CH12-126728>
>> 
> 
> All it says about NSImage is: "One thread can create an NSImage object, draw 
> to the image buffer, and pass it off to the main thread for drawing. The 
> underlying image cache is shared among all threads.”
> 
> So it sounds like the problem isn’t the new NSImage but the existing one 
> being drawn into it. It might help to get the NSImage’s imageRep on the main 
> thread and then pass that to the background thread.
> 
> (I’ve got some similar code in one of my apps that creates NSImages on a 
> parallel dispatch queue and draws into them, but it only draws text, not any 
> pre-existing images. This code works fine even with dozens of tasks at a 
> time.)


Well it also says:

"The following classes and functions are generally not thread-safe. In most 
cases, you can use these classes from any thread as long as you use them from 
only one thread at a time."

and then lists NSImage. That's why a serial queue would probably work...or 
using something else like passing around an image rep as Jens suggests and 
drawing it to a local NSGraphicsContext backed by a NSBitmapImageRep.

-aaron
___

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: NSImage drawInRect deadlock

[Jens Alfke]

> On Aug 8, 2016, at 12:46 PM, Aaron Tuller <mandelb...@mac.com> wrote:
> 
> Search for NSImage here:
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/1057i-CH12-126728
>  
> <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/1057i-CH12-126728>
> 

All it says about NSImage is: "One thread can create an NSImage object, draw to 
the image buffer, and pass it off to the main thread for drawing. The 
underlying image cache is shared among all threads.”

So it sounds like the problem isn’t the new NSImage but the existing one being 
drawn into it. It might help to get the NSImage’s imageRep on the main thread 
and then pass that to the background thread.

(I’ve got some similar code in one of my apps that creates NSImages on a 
parallel dispatch queue and draws into them, but it only draws text, not any 
pre-existing images. This code works fine even with dozens of tasks at a time.)

—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: NSImage drawInRect deadlock

[Aaron Tuller]

Search for NSImage here:

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/1057i-CH12-126728

It sounds like you may need to do this serially, or try setting the cache mode 
to NSImageCacheNever right after you create the new NSImage to see if you can 
avoid hitting the shared cache.

Alternatively, you might want to look into using NSBitmapImageRep or 
CGImageSourceCreateThumbnailAtIndex.

-aaron


> On Aug 8, 2016, at 11:05 AM, Andrew Keller <and...@kellerfarm.com> wrote:
> 
> Hi all,
> 
> In my app, I’m creating thumbnails of images.  To do this in parallel, I’m 
> using the global background dispatch queue:
> 
> dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 
> 0), ^{
>@autoreleasepool {
>NSSize *thumbnailSize = // calculate thumbnail size
>NSImage *thumbnail = [img imageByResizingTo:thumbnailSize];
>// Do stuff with result
>}
> });
> 
> I have this in a category extension on NSImage:
> 
> - (NSImage *)imageByResizingTo:(NSSize)newSize {
>NSImage *newImage = [[NSImage alloc] initWithSize:newSize];
>NSSize currentSize = [self size];
>NSRect currentRect = NSMakeRect(0, 0, currentSize.width, 
> currentSize.height);
>NSRect newRect = NSMakeRect(0, 0, newSize.width, newSize.height);
> 
>[newImage lockFocus];
>[self drawInRect:newRect fromRect:currentRect operation:NSCompositeCopy 
> fraction:1.0f];
>[newImage unlockFocus];
> 
>return newImage;
> }
> 
> However, when enough images are being processed simultaneously, the 
> background threads servicing the queue appear to all lock up with this stack 
> trace:
> 
> #00x7fff93d2951a in semaphore_wait_trap ()
> #10x7fff8b75ac5b in _os_semaphore_wait ()
> #20x000100074e12 in _dispatch_barrier_sync_f_slow ()
> #30x7fff89315182 in ___lldb_unnamed_function872$$RawCamera ()
> #40x7fff86a98e26 in ImageProviderCopyImageBlockSetCallback ()
> #50x7fff877d5279 in img_blocks_create ()
> #60x7fff87804598 in img_blocks_extent ()
> #70x7fff877c55b0 in img_data_lock ()
> #80x7fff877c25a6 in CGSImageDataLock ()
> #90x7fff8be62a02 in ripc_AcquireImage ()
> #10   0x7fff8be61525 in ripc_DrawImage ()
> #11   0x7fff877c21b0 in CGContextDrawImage ()
> #12   0x7fff8ee9627d in __75-[NSBitmapImageRep 
> _withoutChangingBackingPerformBlockUsingBackingCGImage:]_block_invoke ()
> #13   0x7fff8ee95969 in -[NSBitmapImageRep 
> _withoutChangingBackingPerformBlockUsingBackingCGImage:] ()
> #14   0x7fff8ee958f5 in __53-[NSBitmapImageRep 
> _performBlockUsingBackingCGImage:]_block_invoke ()
> #15   0x7fff8ee95859 in -[NSBitmapImageRep 
> _performBlockUsingBackingCGImage:] ()
> #16   0x7fff8ee957b4 in -[NSBitmapImageRep CGImage] ()
> #17   0x7fff8ee95719 in -[NSBitmapImageRep 
> CGImageForProposedRect:context:hints:] ()
> #18   0x7fff8ee4e6af in __74-[NSImageRep 
> drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke ()
> #19   0x7fff8ee4e195 in -[NSImageRep 
> drawInRect:fromRect:operation:fraction:respectFlipped:hints:] ()
> #20   0x7fff8f33e656 in __71-[NSImage 
> drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke1012
>  ()
> #21   0x7fff8edf4dc6 in -[NSImage 
> _usingBestRepresentationForRect:context:hints:body:] ()
> #22   0x7fff8ee4d9d7 in -[NSImage 
> drawInRect:fromRect:operation:fraction:respectFlipped:hints:] ()
> #23   0x00018aa5 in -[NSImage(AppKitHelpers) imageByResizingTo:] at 
> /Users/kelleran/Documents/Example/Example/AppKitHelpers.m:43
> [ snip ]
> 
> Then, if I try to do anything in the app such as click a button or quit the 
> app, the main thread locks up too, with this stack trace:
> 
> #00x7fff93d2951a in semaphore_wait_trap ()
> #10x00010006d2d5 in _dispatch_semaphore_wait_slow ()
> #20x7fff908f4da9 in xpc_connection_send_message_with_reply_sync ()
> #30x7fff90b1fe99 in _LSCopyApplicationInformation ()
> #40x7fff90b29a6c in _LSCopyApplicationInformationItem ()
> #50x7fff8ef8d08d in -[NSApplication _copyPublicPersistentUIInfo] ()
> #60x7fff8ef8b570 in recursivelyEncodeInvalidPersistentState ()
> #70x7fff8ef8a13a in -[NSPersistentUIManager 
> flushAllChangesOptionallyWaitingUntilDone:updatingSnapshots:] ()
> #80x7fff8ef89c6b in -[NSPersistentUIManager 
> flushPersistentStateAndClose:waitingUntilDone:] ()
> #90x7fff8ed5c466 in run_cocoa_block ()
> #10   0x7fff8ef89b8e in __42-[NSPersistentUIManager 
> acquireDirtyState]_block_inv

NSImage drawInRect deadlock

[Andrew Keller]

Hi all,

In my app, I’m creating thumbnails of images.  To do this in parallel, I’m 
using the global background dispatch queue:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 
0), ^{
@autoreleasepool {
NSSize *thumbnailSize = // calculate thumbnail size
NSImage *thumbnail = [img imageByResizingTo:thumbnailSize];
// Do stuff with result
}
});

I have this in a category extension on NSImage:

- (NSImage *)imageByResizingTo:(NSSize)newSize {
NSImage *newImage = [[NSImage alloc] initWithSize:newSize];
NSSize currentSize = [self size];
NSRect currentRect = NSMakeRect(0, 0, currentSize.width, 
currentSize.height);
NSRect newRect = NSMakeRect(0, 0, newSize.width, newSize.height);

[newImage lockFocus];
[self drawInRect:newRect fromRect:currentRect operation:NSCompositeCopy 
fraction:1.0f];
[newImage unlockFocus];

return newImage;
}

However, when enough images are being processed simultaneously, the background 
threads servicing the queue appear to all lock up with this stack trace:

#0  0x7fff93d2951a in semaphore_wait_trap ()
#1  0x7fff8b75ac5b in _os_semaphore_wait ()
#2  0x000100074e12 in _dispatch_barrier_sync_f_slow ()
#3  0x7fff89315182 in ___lldb_unnamed_function872$$RawCamera ()
#4  0x7fff86a98e26 in ImageProviderCopyImageBlockSetCallback ()
#5  0x7fff877d5279 in img_blocks_create ()
#6  0x7fff87804598 in img_blocks_extent ()
#7  0x7fff877c55b0 in img_data_lock ()
#8  0x7fff877c25a6 in CGSImageDataLock ()
#9  0x7fff8be62a02 in ripc_AcquireImage ()
#10 0x7fff8be61525 in ripc_DrawImage ()
#11 0x7fff877c21b0 in CGContextDrawImage ()
#12 0x7fff8ee9627d in __75-[NSBitmapImageRep 
_withoutChangingBackingPerformBlockUsingBackingCGImage:]_block_invoke ()
#13 0x7fff8ee95969 in -[NSBitmapImageRep 
_withoutChangingBackingPerformBlockUsingBackingCGImage:] ()
#14 0x7fff8ee958f5 in __53-[NSBitmapImageRep 
_performBlockUsingBackingCGImage:]_block_invoke ()
#15 0x7fff8ee95859 in -[NSBitmapImageRep 
_performBlockUsingBackingCGImage:] ()
#16 0x7fff8ee957b4 in -[NSBitmapImageRep CGImage] ()
#17 0x7fff8ee95719 in -[NSBitmapImageRep 
CGImageForProposedRect:context:hints:] ()
#18 0x7fff8ee4e6af in __74-[NSImageRep 
drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke ()
#19 0x7fff8ee4e195 in -[NSImageRep 
drawInRect:fromRect:operation:fraction:respectFlipped:hints:] ()
#20 0x7fff8f33e656 in __71-[NSImage 
drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke1012 
()
#21 0x7fff8edf4dc6 in -[NSImage 
_usingBestRepresentationForRect:context:hints:body:] ()
#22 0x7fff8ee4d9d7 in -[NSImage 
drawInRect:fromRect:operation:fraction:respectFlipped:hints:] ()
#23 0x00018aa5 in -[NSImage(AppKitHelpers) imageByResizingTo:] at 
/Users/kelleran/Documents/Example/Example/AppKitHelpers.m:43
[ snip ]

Then, if I try to do anything in the app such as click a button or quit the 
app, the main thread locks up too, with this stack trace:

#0  0x7fff93d2951a in semaphore_wait_trap ()
#1  0x00010006d2d5 in _dispatch_semaphore_wait_slow ()
#2  0x7fff908f4da9 in xpc_connection_send_message_with_reply_sync ()
#3  0x7fff90b1fe99 in _LSCopyApplicationInformation ()
#4  0x7fff90b29a6c in _LSCopyApplicationInformationItem ()
#5  0x7fff8ef8d08d in -[NSApplication _copyPublicPersistentUIInfo] ()
#6  0x7fff8ef8b570 in recursivelyEncodeInvalidPersistentState ()
#7  0x7fff8ef8a13a in -[NSPersistentUIManager 
flushAllChangesOptionallyWaitingUntilDone:updatingSnapshots:] ()
#8  0x7fff8ef89c6b in -[NSPersistentUIManager 
flushPersistentStateAndClose:waitingUntilDone:] ()
#9  0x7fff8ed5c466 in run_cocoa_block ()
#10 0x7fff8ef89b8e in __42-[NSPersistentUIManager 
acquireDirtyState]_block_invoke ()
#11 0x000100062fc3 in _dispatch_client_callout ()
[ snip ]

Experimentally, it seems that I need at least 10 to 20-ish threads actively 
performing work from the queue simultaneously for the deadlock to occur.  
However, just because more threads reproduces the issue faster doesn’t mean 
that fewer threads makes the problem go away entirely — it could just be a 
matter of probability and luck.  To guarantee that nothing deadlocks, must I 
perform this work serially, or is there something I’m doing wrong?

Thanks,
 - Andrew Keller

___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

>> 
>> I would think that even with a retain it could get weird...
>> 
>> The main thread wants to use the imageRef property so it calls:
>> 
>> myRef = [window.imageRef];
>> [myref retain];
>> 
>> If right between these calls, the worker thread calls setImageRef (on a
>> property with atomic, copy), then the retain call in the main thread might
>> be on something that has already gone away.
>> 
>> I just don't see how I can safely set the property on a worker thread and
>> read it on the main thread without some risk of it being released behind my
>> back.
> 
> As Graham points out, and as we used to discuss often back in the old MRR
> days, atomic getters likely put the value in the autorelease pool, you should
> go see if that’s the case or not.

How can I tell? I can't even do a retainCount without first calling the
getter.





___

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: NSImage from bitmap - then delete bitmap

[Roland King]

> 
> I would think that even with a retain it could get weird...
> 
> The main thread wants to use the imageRef property so it calls:
> 
> myRef = [window.imageRef];
> [myref retain];
> 
> If right between these calls, the worker thread calls setImageRef (on a
> property with atomic, copy), then the retain call in the main thread might
> be on something that has already gone away.
> 
> I just don't see how I can safely set the property on a worker thread and
> read it on the main thread without some risk of it being released behind my
> back.

As Graham points out, and as we used to discuss often back in the old MRR days, 
atomic getters likely put the value in the autorelease pool, you should go see 
if that’s the case or not, if so, it’s protected for as long as that pool isn’t 
drained, and it’s your pool on the main thread, so it won’t be drained between 
those calls. In that case you don’t even need to add the extra retains, however 
for good practice, why not. 

If atomic getters don’t work like that then they are fairly useless. 
___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> 
>> On 27 Jul 2016, at 12:05 PM, Trygve Inda  wrote:
>> 
>> How is it retained by the main thread without an explicit retain call?
>> 
>> I would be no different than a main thread calling:
>> 
>> someVar [[MyObj alloc] init]
>> [someVar doSomething];
>> 
>> If a worker thread were able to call [someVar release] between these two
>> lines, the doSomething call could fail.
> 
> 
> The atomic setter method probably looks something like this:
> 
> - (void) setImageRep:(NSImageRep*) rep
> {
> @synchronized( self )
> {
> [rep retain];
> [_imageRep autorelease];
> _imageRep = rep;
> }
> }
> 
> i.e. the old value is autoreleased. Which thread’s pool gets that autorelease
> is a matter for consideration though. I have no idea if it’s just left to the
> caller’s pool, or if there are steps taken to ensure it ends up in the main
> pool. Even if it’s the caller’s pool, unless you’re draining it on each loop,
> it may only ever get drained when the thread ends, which is safe. But it could
> accumulate a lot of unreleased memory which is another potential problem.
> 
> Threads are tricky ;)

And BTW I am draining the pool on each loop of the worker thread.




___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> 
>> On 27 Jul 2016, at 10:05, Trygve Inda  wrote:
>> 
>>> 
>> 
>> How is it retained by the main thread without an explicit retain call?
> 
> are you not using ARC? If you are then all such references, both variable and
> during method calls are retained automatically. If you’re not, then do what
> ARC does and retain it explicitly and release it explicitly (and start using
> ARC in that case!)

This is non-ARC code. It is a large project and convertig to ARC is a huge
amount of work.

>> 
>> I would be no different than a main thread calling:
>> 
>> someVar [[MyObj alloc] init]
>> [someVar doSomething];
> 
> That isn’t compilable code. Did you mean
> 
> someVar = [ [ MyObj alloc]init ]
> [ someVar doSomething ];

Yes.

> 
> Again if you’re using ARC, none of these issues are issues.
> 
> Why would a worker thread call [ someVar release ] on a variable it didn’t
> retain in the first place? If that’s actually a realistic scenario and you’re
> not using ARC, then call retain on someVar when you assign it in the first
> place and release it only after you’re finished with it, after the call to
> doSomething. Which, by the way, is pretty much what ARC does.

I would think that even with a retain it could get weird...

The main thread wants to use the imageRef property so it calls:

myRef = [window.imageRef];
[myref retain];

If right between these calls, the worker thread calls setImageRef (on a
property with atomic, copy), then the retain call in the main thread might
be on something that has already gone away.

I just don't see how I can safely set the property on a worker thread and
read it on the main thread without some risk of it being released behind my
back.









___

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: NSImage from bitmap - then delete bitmap

[Roland King]

> On 27 Jul 2016, at 10:05, Trygve Inda  wrote:
> 
>> 
> 
> How is it retained by the main thread without an explicit retain call?

are you not using ARC? If you are then all such references, both variable and 
during method calls are retained automatically. If you’re not, then do what ARC 
does and retain it explicitly and release it explicitly (and start using ARC in 
that case!)

> 
> I would be no different than a main thread calling:
> 
> someVar [[MyObj alloc] init]
> [someVar doSomething];

That isn’t compilable code. Did you mean

someVar = [ [ MyObj alloc]init ]
[ someVar doSomething ];


> 
> If a worker thread were able to call [someVar release] between these two
> lines, the doSomething call could fail.
> 

Again if you’re using ARC, none of these issues are issues. 

Why would a worker thread call [ someVar release ] on a variable it didn’t 
retain in the first place? If that’s actually a realistic scenario and you’re 
not using ARC, then call retain on someVar when you assign it in the first 
place and release it only after you’re finished with it, after the call to 
doSomething. Which, by the way, is pretty much what ARC does. 



> 
> 


___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 27 Jul 2016, at 12:18 PM, Graham Cox  wrote:
> 
> The atomic setter method probably looks something like this:


A further thought. If the getter method is also protected, like:

- (NSImageRep*) imageRep
{
@synchronized( self )
{
return [[_imageRep retain] autorelease];
}
}


Then you’ll also be safe.

I have no idea if this is what synthesized atomic getters look like though.

—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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 27 Jul 2016, at 12:05 PM, Trygve Inda  wrote:
> 
> How is it retained by the main thread without an explicit retain call?
> 
> I would be no different than a main thread calling:
> 
> someVar [[MyObj alloc] init]
> [someVar doSomething];
> 
> If a worker thread were able to call [someVar release] between these two
> lines, the doSomething call could fail.


The atomic setter method probably looks something like this:

- (void)setImageRep:(NSImageRep*) rep
{
@synchronized( self )
{
[rep retain];
[_imageRep autorelease];
_imageRep = rep;
}
}

i.e. the old value is autoreleased. Which thread’s pool gets that autorelease 
is a matter for consideration though. I have no idea if it’s just left to the 
caller’s pool, or if there are steps taken to ensure it ends up in the main 
pool. Even if it’s the caller’s pool, unless you’re draining it on each loop, 
it may only ever get drained when the thread ends, which is safe. But it could 
accumulate a lot of unreleased memory which is another potential problem.

Threads are tricky ;)

—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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> 
>> On 27 Jul 2016, at 09:33, Trygve Inda  wrote:
>> 
>> 
>> 
>> If the worker thread calls window.imageRep = myResult; it is possible that
>> the main thread is in the middle of a call like:
>> 
>> [[window.imageRep]
>> drawInRect:fromRect:operation:fraction:respectFlipped:hints:]
>> 
>> So when the setter (called from the worker thread) replaces the old imageRep
>> with a new one, the old one's retain count goes to zero and it will
>> disappear.
>> 
>> I know atomic makes the call safe as far as a vaild value is concerned, but
>> the main thread could call window.imageRep and get a valid value (because it
>> is atomic), but before it is able to use this value, the worker thread calls
>> the setter which causes the imageRep obtained by the main thread to be
>> released.
> 
> No it couldn’t - because when the main thread calls window.imageRep it gets a
> reference which, whether it assigns it to a variable or just uses it in in a
> chained call (like you have above with drawInRect:.) is retained by the main
> thread during the life of that variable or during the call. So it doesn’t
> matter if the worker thread replaces it after the call to window.imageRep, the
> main thread’s reference remains valid and usable and is only released when
> it’s finished with it and only then gets deallocated (if nothing else is
> referencing it)
> 

How is it retained by the main thread without an explicit retain call?

I would be no different than a main thread calling:

someVar [[MyObj alloc] init]
[someVar doSomething];

If a worker thread were able to call [someVar release] between these two
lines, the doSomething call could fail.




___

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: NSImage from bitmap - then delete bitmap

[Roland King]

> On 27 Jul 2016, at 09:33, Trygve Inda  wrote:
> 
> 
> 
> If the worker thread calls window.imageRep = myResult; it is possible that
> the main thread is in the middle of a call like:
> 
> [[window.imageRep] 
> drawInRect:fromRect:operation:fraction:respectFlipped:hints:]
> 
> So when the setter (called from the worker thread) replaces the old imageRep
> with a new one, the old one's retain count goes to zero and it will
> disappear.
> 
> I know atomic makes the call safe as far as a vaild value is concerned, but
> the main thread could call window.imageRep and get a valid value (because it
> is atomic), but before it is able to use this value, the worker thread calls
> the setter which causes the imageRep obtained by the main thread to be
> released.

No it couldn’t - because when the main thread calls window.imageRep it gets a 
reference which, whether it assigns it to a variable or just uses it in in a 
chained call (like you have above with drawInRect:.) is retained by the main 
thread during the life of that variable or during the call. So it doesn’t 
matter if the worker thread replaces it after the call to window.imageRep, the 
main thread’s reference remains valid and usable and is only released when it’s 
finished with it and only then gets deallocated (if nothing else is referencing 
it)


___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> e.g.
> 
> worker thread:
> 
> while( self.running )
> {
> // do work
> 
> window.imageRep = myResult;  // window.imageRep is (atomic, copy)
> 
> [performOnMainThread: window.setNeedsDisplay];  // this is obviously
> pseudocode!
> }
> 
> 
> main thread, when it needs to terminate worker thread:
> 
> workerThread.running = NO;
> 
> 
> both workerThread.running and window.imageRep are atomic properties.

I am not sure this is safe.

window.imageRep is (atomic, copy)

If the worker thread calls window.imageRep = myResult; it is possible that
the main thread is in the middle of a call like:

[[window.imageRep] 
drawInRect:fromRect:operation:fraction:respectFlipped:hints:]

So when the setter (called from the worker thread) replaces the old imageRep
with a new one, the old one's retain count goes to zero and it will
disappear.

I know atomic makes the call safe as far as a vaild value is concerned, but
the main thread could call window.imageRep and get a valid value (because it
is atomic), but before it is able to use this value, the worker thread calls
the setter which causes the imageRep obtained by the main thread to be
released.

I think you'd only want to call the setter from the main thread.



___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 23 Jul 2016, at 4:09 PM, Ken Thomases <k...@codeweavers.com> wrote:
> 
> No, because the main thread may not have started servicing the 
> performSelector request yet.  The background thread has blocked as soon as 
> the request is _queued_ for the main thread, not just once the main thread 
> has received the request.  If the main thread makes a synchronous request to 
> the background thread before it gets back to the run loop to service the 
> pending performSelector request, it will deadlock.
> 


I’m trying to get my head around this.

If -performSelectorOnMainThread is called with a waitUntilDone:YES, then that 
whole call must be surrounded by a lock (?)

The main thread may be doing other things and take its time to get around to 
this. One of the things it could do is to try to terminate the thread that is 
blocked waiting on the performSelector. OK, fair enough. But how can that call 
to terminate the thread itself block? If it synchronously waits for the thread 
to terminate, then yes, I can see that would be a bad idea. But is that a 
reasonable scenario? What if the “termination” is just setting a flag that the 
other thread checks? That would surely be safe?

What does “thread termination” mean anyway? Even at the lower levels of 
threads, isn’t the scheduler really just setting a similar flag? When the 
thread gets unblocked, the scheduler checks that flag to see if the thread 
should get further time or killed.

Seems to me *something* has to be on the outside of all the locking, blocking 
and running and that something would be the scheduler. Otherwise threads would 
deadlock all the time and that isn’t really the case - you normally have to go 
out of your way to do something silly to cause that.

Anyway, haven’t we establishd that passing YES to waitUntilDone: here isn’t 
necessary? Performing the copy should avoid the need.

Another thing:

Also, further thinking about that copy, I seem to recall that NSBitmapImageRep 
has a copy-on-write setup, so that at first that call to -copy will be quick 
and cheap - both resulting objects share the pixel buffer. If one or the other 
of those objects then calls -bitmapData, then a unique copy of its buffer will 
need to be made, on the assumption that something’s going to write to the 
buffer. If this is the worker thread, effectively it’s making a new buffer just 
as Roland suggested you could do manually. That’s provided that the worker 
thread calls -bitmapData at the start of its work, and doesn’t cache that 
pointer or assume it never changes with each outer run of the thread’s loop.

Given this, the original outline is a workable one - the worker thread never 
needs to wait or block on the main thread, it can pass the bitmap across to the 
window as an (atomic, copy) property, and as long as it calls -bitmapData as it 
starts the next chunk of work, it will be as performant as Roland’s idea of 
making a new bitmap each time, if not slightly more so.

Having said all that, the copy-on-write behaviour is something I can’t find any 
hard documentation for. I seem to recall that this came up in a discussion 
about NSImage/NSBitmapImageRep a long time ago just after the internal 
behaviour of these classes was overhauled. That may have been in the 10.5 or 
even earlier era.

—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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> On Jul 22, 2016, at 19:29 , Graham Cox  wrote:
>> 
>> If the worker thread is waiting for -performOnMainThread to complete, it
>> *cannot* possibly get a call from the main thread to terminate
> 
> I nodded agreement when I first read this, then “but wait!” …
> 
> Your logic seems flawed on two counts:
> 
> 1. The selector performed by the worker thread may still be queued, so the
> main thread is doing something else which may result in an attempt to
> terminate the worker thread.

This exactly. We have seen it happen 5 times out of potentially millions of
runs. Only recently did we track down what is happening through a lucky
report submitted by a customer.

T.




___

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: NSImage from bitmap - then delete bitmap

[Ken Thomases]

On Jul 22, 2016, at 9:29 PM, Graham Cox  wrote:
> 
> 
>> On 23 Jul 2016, at 12:45 AM, Trygve Inda  wrote:
>> 
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it does this after performOnMainThread has been called by a
>> worker thread, but before the main thread has processed it, then the main
>> thread will block waiting for the worker thread to exit, but the worker
>> thread has already blocked when it called performOnMainThread.
>> 
>> Very rare, but it can happen.
> 
> This is wrong thinking.
> 
> If the worker thread is waiting for -performOnMainThread to complete, it 
> *cannot* possibly get a call from the main thread to terminate, because the 
> main thread is dealing with whatever the other thread asked it to do.

No, because the main thread may not have started servicing the performSelector 
request yet.  The background thread has blocked as soon as the request is 
_queued_ for the main thread, not just once the main thread has received the 
request.  If the main thread makes a synchronous request to the background 
thread before it gets back to the run loop to service the pending 
performSelector request, it will deadlock.

Regards,
Ken


___

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: NSImage from bitmap - then delete bitmap

[Quincey Morris]

On Jul 22, 2016, at 19:29 , Graham Cox  wrote:
> 
> If the worker thread is waiting for -performOnMainThread to complete, it 
> *cannot* possibly get a call from the main thread to terminate

I nodded agreement when I first read this, then “but wait!” …

Your logic seems flawed on two counts:

1. The selector performed by the worker thread may still be queued, so the main 
thread is doing something else which may result in an attempt to terminate the 
worker thread.

2. The worker method performed on the main thread may directly or indirectly 
lead to an attempt to terminate the worker thread.

Both scenarios could cause a deadlock. At least, that’s my attempt at logic.

The real problem is that it’s simply a bug to have two threads with mutual, 
synchronous, unconditional waits. Of course that’s going to deadlock eventually.

___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 23 Jul 2016, at 12:45 AM, Trygve Inda  wrote:
> 
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block waiting for the worker thread to exit, but the worker
> thread has already blocked when it called performOnMainThread.
> 
> Very rare, but it can happen.


This is wrong thinking.

If the worker thread is waiting for -performOnMainThread to complete, it 
*cannot* possibly get a call from the main thread to terminate, because the 
main thread is dealing with whatever the other thread asked it to do.

If the worker thread performs a copy and doesn’t wait for the main thread to 
perform the drawing, then it’s still “blocked” while it’s performing the copy.

Either your understanding of the bug is wrong, or there’s somethomg whiffy in 
your architecture.

Usually a worker thread just checks a flag on each loop and falls out when it 
gets set (by another thread). That flag should be set atomically. There can 
then be no deadlock.

e.g.

worker thread:

while( self.running )
{
// do work

window.imageRep = myResult; 
// window.imageRep is (atomic, copy)

[performOnMainThread: window.setNeedsDisplay];  // this is 
obviously pseudocode!
}


main thread, when it needs to terminate worker thread:

workerThread.running = NO;


both workerThread.running and window.imageRep are atomic properties.


—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: NSImage from bitmap - then delete bitmap

[Alan Snyder]

Or better yet, have the termination request come from a thread other than the 
main thread.

> On Jul 22, 2016, at 9:38 AM, Alan Snyder  wrote:
> 
> 
>> On Jul 22, 2016, at 7:45 AM, Trygve Inda  wrote:
>> 
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it does this after performOnMainThread has been called by a
>> worker thread, but before the main thread has processed it, then the main
>> thread will block waiting for the worker thread to exit, but the worker
>> thread has already blocked when it called performOnMainThread.
>> 
>> Very rare, but it can happen.
> 
> This sounds like a bug to me.
> 
> Would this work: The worker thread could set a flag before it calls 
> performOnMainThread and your thread termination code could do something 
> different when this flag is set.
> 


___

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: NSImage from bitmap - then delete bitmap

[Alan Snyder]

> On Jul 22, 2016, at 7:45 AM, Trygve Inda  wrote:
> 
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block waiting for the worker thread to exit, but the worker
> thread has already blocked when it called performOnMainThread.
> 
> Very rare, but it can happen.

This sounds like a bug to me.

Would this work: The worker thread could set a flag before it calls 
performOnMainThread and your thread termination code could do something 
different when this flag is set.

___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

 
>> Currently it blocks at this point, but I need to avoid that.
> 
> It’s not really clear why this needs to be avoided. The time to draw the
> pixels should be a few milliseconds, a small fraction of the time your thread
> needs to run, even at its fastest.

Because the main thread sometimes needs to ask the worker threads to
terminate. If it does this after performOnMainThread has been called by a
worker thread, but before the main thread has processed it, then the main
thread will block waiting for the worker thread to exit, but the worker
thread has already blocked when it called performOnMainThread.

Very rare, but it can happen.

>> Since it can't
>> block,
>> the pixels need to be copied to the main thread because as soon as
>> they get handed to the main thread, the worker thread will erase the
>> original pixel buffer to start drawing a new image into it.
> 
> Copying the image is likely to be just as slow/fast as drawing it, so the copy
> isn’t going to help speed up your thread. Both operations have to iterate over
> the pixels; drawing *IS* copying.

Speed isn't really the issue. The issue is changing the code so that the
worker thread never has to block. To do so the pixels need to handed off to
the main thread in such a way that the worker thread can then destroy the
original pixels (by writing over them with new data)

>> The copy needs to exist long enough to be drawn into a window by the main
>> thread and can then be released.
> 
> Understood, but you may as well keep it around until the next version of the
> image is passed across - the previous one will be released at the same time
> when setting the property.

Yup - that's possible too.




___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 22 Jul 2016, at 11:53 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
> How can I draw the NSImageRep  directly into a window?


-[NSImageRep drawInRect:fromRect:operation:fraction:respectFlipped:hints:];

i.e. same as NSImage.


> 
> Also, the main pixel buffer is updated slowly (it takes a long time to
> draw). So once the worker thread is done, it needs to pass off those pixels
> to the main thread to be drawn.
> 
> Currently it blocks at this point, but I need to avoid that.

It’s not really clear why this needs to be avoided. The time to draw the pixels 
should be a few milliseconds, a small fraction of the time your thread needs to 
run, even at its fastest.

> Since it can't
> block,
> the pixels need to be copied to the main thread because as soon as
> they get handed to the main thread, the worker thread will erase the
> original pixel buffer to start drawing a new image into it.

Copying the image is likely to be just as slow/fast as drawing it, so the copy 
isn’t going to help speed up your thread. Both operations have to iterate over 
the pixels; drawing *IS* copying.

> The copy needs to exist long enough to be drawn into a window by the main
> thread and can then be released.

Understood, but you may as well keep it around until the next version of the 
image is passed across - the previous one will be released at the same time 
when setting the property.


—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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> 
>> On 22 Jul 2016, at 4:08 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
>> 
>> I don't think the second part will work because of my workflow:
>> 
>> At Launch: Create pixel buffer that is 1000 x 1000 pixels
>> 
>> Looping thread
>> 1. Fill pixel buffer with pixels based on some algorithm
>> 2. create an NSImage with these pixels
>> 3. pass it to the main thread to be drawn in a window
>> Restart the loop with a  slightly modified algorithm
>> 
>> If calling this:
>> [myImage addRepresentation:theBitmapIMadeFirst];
>> 
>> Only causes the NSImage to retain it, then when I change the pixels in the
>> bitmap, they get changed in the NSImage.
>> 
>> I need the NSImage to keep the pixels as they existed when I created it.
> 
> 
> Do you?
> 
> Once the image is drawn into the window, it’s effectively copied to the
> window’s backing store, so there’s already a second copy of the pixels.
> 
> The only situation that might cause a problem is if the window can possibly be
> called upon to redraw at a time when the bitmap is being updated but hasn’t
> yet completed. If the code that fills the buffer is synchronous, that can
> never happen. If the code is asynchronous (e.g. on a second thread), then you
> *might* want a copy of the bitmap, but only if drawing it halfway through
> updating would actually be bad - that depends entirely on what is being drawn.
> If it’s a minor/subtle change, it may not be noticeable.
> 
> With half an eye on performance, if you *do* strictly need a copy of the
> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
> turn it into a TIFF and back again.
> 
> Also, you don’t even need an NSImage - the NSImageRep can be drawn directly.

How can I draw the NSImageRep  directly into a window?

Also, the main pixel buffer is updated slowly (it takes a long time to
draw). So once the worker thread is done, it needs to pass off those pixels
to the main thread to be drawn.

Currently it blocks at this point, but I need to avoid that. Since it can't
block, the pixels need to be copied to the main thread because as soon as
they get handed to the main thread, the worker thread will erase the
original pixel buffer to start drawing a new image into it.

The copy needs to exist long enough to be drawn into a window by the main
thread and can then be released.





___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

 
>> This is how it works now, but we are running into a rare deadlock situation
>> where the main thread asks the worker thread to end (and waits until it does
>> so) while the worker thread is waiting for the image to be displayed.
> 
> If the window has a imageRep property that is (atomic, copy) you shouldn’t run
> into a deadlock where the window tries to terminate the thread and it happens
> to be calling that method at the time. If you go with Roland’s suggestion, it
> doesn’t need to be copy, it can simply be strong. But make it atomic, as the
> property will need to be accessed from both the main and the worker threads
> and the rep must be in a viable state at both times.

Ultimately there needs to be more than one copy of the pixels because as
soon as the worker thread is done building the image, it hands it off to the
main thread to be displayed.

Currently it blocks until the main thread displays it, so only one set of
pixels is needed. But to prevent deadlock, the worker thread really needs to
just hand of a copy of the pixels, then erase the original pixels and start
a new image.

[bitmapImageRep copy] might be the best solution here.

T.




___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 22 Jul 2016, at 5:30 PM, Quincey Morris 
>  wrote:
> 
> On Jul 22, 2016, at 00:08 , Graham Cox  wrote:
>> 
>> If the thread building images never goes faster than once per second, the 
>> time to draw the image is a fraction of that - I’m sure 60fps is achievable, 
>> so making the thread wait for the drawing to be done isn’t going to hold it 
>> up significantly. 
> 
> (I’ve done something like this, though it was a couple of years ago, so the 
> same performance characteristics cannot be assumed.)
> 
> With the sequence:
> 
>   worker thread -> NSBitmapImageRep -> main thread -> window
> 
> not even 24 fps was achievable, for anything but fairly small images (say, 
> less than one quarter of a 21-inch non-Retina screen). That’s because a 
> bitmap image rep isn’t the internal representation of anything, so there 
> always a copy or two, along with a possible pixel format translation, and a 
> colorspace mapping.

A possible optimisation there would be to use -[NSView 
bitmapImageRepForCachingDisplayInRect:] which returns a rep that matches the 
backing store format and colorspace, so copying is fast. That might put more 
strain on the renderer code though, which has to deal with the format it finds, 
not one it created.

> OTOH, I’m not sure 60fps is being asked for, unless that comes from your 
> special knowledge of what the app does. It was less than 1 fps per worker 
> thread, and if there are 60+ worker threads, there are likely other 
> performance issues as well.
> 

It’s not being asked for - 1fps is the fastest. But I meant that if the drawing 
time is in the 60fps ballpark, then that part isn’t going to hold up the 1fps 
worker thread significanty. I *think* (correct me if I’m wrong Trygve) that 
there’s only one such worker thread.


> On 22 Jul 2016, at 5:19 PM, Trygve Inda  wrote:
> 
> This is how it works now, but we are running into a rare deadlock situation
> where the main thread asks the worker thread to end (and waits until it does
> so) while the worker thread is waiting for the image to be displayed.

If the window has a imageRep property that is (atomic, copy) you shouldn’t run 
into a deadlock where the window tries to terminate the thread and it happens 
to be calling that method at the time. If you go with Roland’s suggestion, it 
doesn’t need to be copy, it can simply be strong. But make it atomic, as the 
property will need to be accessed from both the main and the worker threads and 
the rep must be in a viable state at both times.

—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: NSImage from bitmap - then delete bitmap

[Quincey Morris]

On Jul 22, 2016, at 00:08 , Graham Cox  wrote:
> 
> If the thread building images never goes faster than once per second, the 
> time to draw the image is a fraction of that - I’m sure 60fps is achievable, 
> so making the thread wait for the drawing to be done isn’t going to hold it 
> up significantly. 

(I’ve done something like this, though it was a couple of years ago, so the 
same performance characteristics cannot be assumed.)

With the sequence:

worker thread -> NSBitmapImageRep -> main thread -> window

not even 24 fps was achievable, for anything but fairly small images (say, less 
than one quarter of a 21-inch non-Retina screen). That’s because a bitmap image 
rep isn’t the internal representation of anything, so there always a copy or 
two, along with a possible pixel format translation, and a colorspace mapping. 
Plus multithreading overheads like locks. The details will depend on the Mac, 
the OS version and the display.

If something performant is necessary, then the best approach is probably to use 
CVPixelBuffer instead. However, the learning curve for this is pretty 
horrendous, particular when dealing with isolated still images rather than 
video, so I would not suggest going there unless absolutely necessary.

OTOH, I’m not sure 60fps is being asked for, unless that comes from your 
special knowledge of what the app does. It was less than 1 fps per worker 
thread, and if there are 60+ worker threads, there are likely other performance 
issues as well.

___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> 
>> On 22 Jul 2016, at 4:40 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
>> 
>> 
>>> With half an eye on performance, if you *do* strictly need a copy of the
>>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>>> turn it into a TIFF and back again.
>>> 
>>> Also, you don’t even need an NSImage - the NSImageRep can be drawn directly.
>> 
>> 
>> A little deeper discussion of how my app works.
> 
> I have an idea I know what this app is, so I understand what you need to do. I
> won’t name names if you don’t :) I believe I am a registered user.
> 
> 
>> 
>> I have a background worker thread whose purpose is to generate a continuous
>> series of NSImages - from one per second to one every 5 minutes or so). I
>> may have several of these worker threads working on different images.
>> 
>> The thread starts by making a pixel buffer using:
>> 
>> [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL ..
>> 
>> Then the thread goes into a loop where on each pass it draws the correct
>> image into this pixel buffer.
>> 
>> After the image is drawn it need to be handed off to the main thread to be
>> drawn into a window.
>> 
>> As soon as it is handed off, the thread starts drawing a new image,
>> destroying the pixels used to create the image that was just handed off.
>> 
>> It is likely that the image will not be received by the main thread and
>> drawn into the window before the pixels in the NSBitmapImageRep  are
>> destroyed (because it the thread is now drawing a new image).
>> 
>> So how is the best way to take my NSBitmapImageRep, and hand it off to the
>> main thread in such a way that I can destroy the pixels immediately while
>> the main thread keeps them?
>> 
>> Would it be best to just call [myImagerep copy], and hand that to the main
>> thread, and let the main thread release it once it has draw it into the
>> window?
>> 
> 
> 
> I have an idea I know what this app is, so I understand what you need to do. I
> won’t name names if you don’t :) I believe I am a registered user.> I think
> you have two choices.

Without naming names, I am sure your hunch is accurate.
 
> You can pass the rep to the window using
> performSelectorOnMainThread:withObject:waitUntilDone: passing YES for wait
> until done, in which case your worker thread will be stalled just long enough
> to draw the image and copy to the backing store. After that you’re free to
> continue modifying the rep.

This is how it works now, but we are running into a rare deadlock situation
where the main thread asks the worker thread to end (and waits until it does
so) while the worker thread is waiting for the image to be displayed.

I have never seen it happen here, but I have tracked it down from hang
reports and need to figure out the best way to hand the pixels off to the
main thread in such a way that there are no dependencies on the original
pixel buffer because as soon as the pixels are handed to the main thread,
the worker thread will be changing the pixels in the original buffer.





___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 22 Jul 2016, at 5:00 PM, Roland King  wrote:
> 
> Since you need the data to persist for display whilst you write a new image 
> that means there’s two separate buffers, there has to be

Not sure there HAS to be. Whether it’s the easiest approach is another matter.

If the thread building images never goes faster than once per second, the time 
to draw the image is a fraction of that - I’m sure 60fps is achievable, so 
making the thread wait for the drawing to be done isn’t going to hold it up 
significantly. You’re going to waste exactly the same amount of time doing a 
copy. Your suggestion of making a new buffer is a good one, as there’s no 
wasted time, provided that the worker thread does set every pixel. Otherwise 
it’s going to have to clear it and you’re back to a pass over the pixels which 
takes the same time as the copy/draw, etc.

But is it worth it to save the 4MB per bitmap? Once upon a time the answer 
would definitely be yes, but 4MB isn’t much these days.

—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: NSImage from bitmap - then delete bitmap

[Roland King]

> On 22 Jul 2016, at 14:40, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
> 
>> With half an eye on performance, if you *do* strictly need a copy of the
>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>> turn it into a TIFF and back again.
>> 
>> Also, you don’t even need an NSImage - the NSImageRep can be drawn directly.
> 
> 
> 
> So how is the best way to take my NSBitmapImageRep, and hand it off to the
> main thread in such a way that I can destroy the pixels immediately while
> the main thread keeps them?
> 
> Would it be best to just call [myImagerep copy], and hand that to the main
> thread, and let the main thread release it once it has draw it into the
> window?
> 

I’d have said the best way is to create a new image buffer for each new image 
you draw, draw into it and hand it off, then make another new one instead of 
trying to use one single one per thread. Creating them is cheap, it’s basically 
malloc(). Since you need the data to persist for display whilst you write a new 
image that means there’s two separate buffers, there has to be. So either you 
make a copy, which means going through the expense of copying it, or you just 
hand it off and start a new one, which doesn’t. When the main thread has 
finished with it it can dispose of the old buffer. 
___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 22 Jul 2016, at 4:40 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
> 
>> With half an eye on performance, if you *do* strictly need a copy of the
>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>> turn it into a TIFF and back again.
>> 
>> Also, you don’t even need an NSImage - the NSImageRep can be drawn directly.
> 
> 
> A little deeper discussion of how my app works.

I have an idea I know what this app is, so I understand what you need to do. I 
won’t name names if you don’t :) I believe I am a registered user.


> 
> I have a background worker thread whose purpose is to generate a continuous
> series of NSImages - from one per second to one every 5 minutes or so). I
> may have several of these worker threads working on different images.
> 
> The thread starts by making a pixel buffer using:
> 
> [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL ..
> 
> Then the thread goes into a loop where on each pass it draws the correct
> image into this pixel buffer.
> 
> After the image is drawn it need to be handed off to the main thread to be
> drawn into a window.
> 
> As soon as it is handed off, the thread starts drawing a new image,
> destroying the pixels used to create the image that was just handed off.
> 
> It is likely that the image will not be received by the main thread and
> drawn into the window before the pixels in the NSBitmapImageRep  are
> destroyed (because it the thread is now drawing a new image).
> 
> So how is the best way to take my NSBitmapImageRep, and hand it off to the
> main thread in such a way that I can destroy the pixels immediately while
> the main thread keeps them?
> 
> Would it be best to just call [myImagerep copy], and hand that to the main
> thread, and let the main thread release it once it has draw it into the
> window?
> 


I think you have two choices.

You can pass the rep to the window using 
performSelectorOnMainThread:withObject:waitUntilDone: passing YES for wait 
until done, in which case your worker thread will be stalled just long enough 
to draw the image and copy to the backing store. After that you’re free to 
continue modifying the rep.

Or you can copy the rep and not bother waiting. One way to do that easily is to 
make the window’s ‘imageRep’ propery ‘copy’ and it’ll do it for you. But you’ll 
also need to call -setNeedsDisplay: on the main thread, again without waiting. 
I don’t think there’s any real advantage one way or the other - one will use 
quite a lot of memory, the other might be ever so slightly slower. Classic 
tradeoff. 

Note that unless you deliberately mark the window as needing display, your 
window will NEVER draw from the rep, even if the user moves it revealing a 
covered portion - that will be filled from the backing store.

—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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> With half an eye on performance, if you *do* strictly need a copy of the
> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
> turn it into a TIFF and back again.
> 
> Also, you don’t even need an NSImage - the NSImageRep can be drawn directly.


A little deeper discussion of how my app works.

I have a background worker thread whose purpose is to generate a continuous
series of NSImages - from one per second to one every 5 minutes or so). I
may have several of these worker threads working on different images.

The thread starts by making a pixel buffer using:

[[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL ..

Then the thread goes into a loop where on each pass it draws the correct
image into this pixel buffer.

After the image is drawn it need to be handed off to the main thread to be
drawn into a window.

As soon as it is handed off, the thread starts drawing a new image,
destroying the pixels used to create the image that was just handed off.

It is likely that the image will not be received by the main thread and
drawn into the window before the pixels in the NSBitmapImageRep  are
destroyed (because it the thread is now drawing a new image).

So how is the best way to take my NSBitmapImageRep, and hand it off to the
main thread in such a way that I can destroy the pixels immediately while
the main thread keeps them?

Would it be best to just call [myImagerep copy], and hand that to the main
thread, and let the main thread release it once it has draw it into the
window?





___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 22 Jul 2016, at 4:08 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
> I don't think the second part will work because of my workflow:
> 
> At Launch: Create pixel buffer that is 1000 x 1000 pixels
> 
> Looping thread
> 1. Fill pixel buffer with pixels based on some algorithm
> 2. create an NSImage with these pixels
> 3. pass it to the main thread to be drawn in a window
> Restart the loop with a  slightly modified algorithm
> 
> If calling this:
> [myImage addRepresentation:theBitmapIMadeFirst];
> 
> Only causes the NSImage to retain it, then when I change the pixels in the
> bitmap, they get changed in the NSImage.
> 
> I need the NSImage to keep the pixels as they existed when I created it.


Do you?

Once the image is drawn into the window, it’s effectively copied to the 
window’s backing store, so there’s already a second copy of the pixels.

The only situation that might cause a problem is if the window can possibly be 
called upon to redraw at a time when the bitmap is being updated but hasn’t yet 
completed. If the code that fills the buffer is synchronous, that can never 
happen. If the code is asynchronous (e.g. on a second thread), then you
*might* want a copy of the bitmap, but only if drawing it halfway through 
updating would actually be bad - that depends entirely on what is being drawn. 
If it’s a minor/subtle change, it may not be noticeable.

With half an eye on performance, if you *do* strictly need a copy of the 
bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to 
turn it into a TIFF and back again.

Also, you don’t even need an NSImage - the NSImageRep can be drawn directly.

—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: NSImage from bitmap - then delete bitmap

[Ken Thomases]

On Jul 22, 2016, at 1:08 AM, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
>> But that’s not a great way to do this. You’ve made an image, you’ve encoded 
>> it
>> as TIFF data, then you’ve made a new image, which has decoded the TIFF data 
>> to
>> make a new image rep/bitmap.
>> 
>> You could just add the representation directly to a new NSImage (warning:
>> typed into Mail, check method names):
>> 
>> NSImage* myImage = [[NSImage alloc] initWithSize:NSMakeSize(width,height)];
>> 
>> [myImage addRepresentation:theBitmapIMadeFirst];
>> 
>> [theBitmapIMadeFirst release]; // because NSImage retained it
> 
> 
> I don't think the second part will work because of my workflow:
> 
> At Launch: Create pixel buffer that is 1000 x 1000 pixels
> 
> Looping thread
> 1. Fill pixel buffer with pixels based on some algorithm
> 2. create an NSImage with these pixels
> 3. pass it to the main thread to be drawn in a window
> Restart the loop with a  slightly modified algorithm
> 
> If calling this:
> [myImage addRepresentation:theBitmapIMadeFirst];
> 
> Only causes the NSImage to retain it, then when I change the pixels in the
> bitmap, they get changed in the NSImage.
> 
> I need the NSImage to keep the pixels as they existed when I created it.

Hint: NSBitmapImageRep conforms to the NSCopying protocol.

Regards,
Ken


___

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: NSImage from bitmap - then delete bitmap

[Trygve Inda]

> 
>> On 22 Jul 2016, at 3:37 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
>> 
>> I create an NSBitmapImageRep:
>> 
>> [[[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL
>> pixelsWide:pixelSize.width
>> pixelsHigh:pixelSize.height
>> bitsPerSample:8
>> samplesPerPixel:4
>> hasAlpha:YES
>> isPlanar:NO
>> colorSpaceName:NSDeviceRGBColorSpace
>> bitmapFormat:NSAlphaFirstBitmapFormat
>> bytesPerRow:pixelSize.width * 4
>> bitsPerPixel:32]
>> 
>> I then get the address by sending a "bitmapData" message to the object
>> 
>> After filling it with image data, I call:
>> 
>> NSImage* image =
>> [[NSImage alloc] initWithData:[myImageRep TIFFRepresentation]];
>> 
>> So now I have an NSImage. What happens if I delete/release myImageRep (my
>> NSBitmapImageRep)?
> 
> Nothing. The rep isn’t doing anything after this point; you can release it
> safely.
> 
>> Has the call to NSImage copied my pixels so that they are self-contained
>> within the NSImage?
> 
> Yes.
> 
> But that’s not a great way to do this. You’ve made an image, you’ve encoded it
> as TIFF data, then you’ve made a new image, which has decoded the TIFF data to
> make a new image rep/bitmap.
> 
> You could just add the representation directly to a new NSImage (warning:
> typed into Mail, check method names):
> 
> NSImage* myImage = [[NSImage alloc] initWithSize:NSMakeSize(width,height)];
> 
> [myImage addRepresentation:theBitmapIMadeFirst];
> 
> [theBitmapIMadeFirst release]; // because NSImage retained it


I don't think the second part will work because of my workflow:

At Launch: Create pixel buffer that is 1000 x 1000 pixels

Looping thread
1. Fill pixel buffer with pixels based on some algorithm
2. create an NSImage with these pixels
3. pass it to the main thread to be drawn in a window
Restart the loop with a  slightly modified algorithm

If calling this:
[myImage addRepresentation:theBitmapIMadeFirst];

Only causes the NSImage to retain it, then when I change the pixels in the
bitmap, they get changed in the NSImage.

I need the NSImage to keep the pixels as they existed when I created it.




___

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: NSImage from bitmap - then delete bitmap

[Ken Thomases]

On Jul 22, 2016, at 12:37 AM, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
> I create an NSBitmapImageRep:
> 
> [[[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL
> pixelsWide:pixelSize.width
> pixelsHigh:pixelSize.height
> bitsPerSample:8
> samplesPerPixel:4
> hasAlpha:YES
> isPlanar:NO
> colorSpaceName:NSDeviceRGBColorSpace
> bitmapFormat:NSAlphaFirstBitmapFormat
> bytesPerRow:pixelSize.width * 4
> bitsPerPixel:32]
> 
> I then get the address by sending a "bitmapData" message to the object
> 
> After filling it with image data, I call:
> 
> NSImage* image =
> [[NSImage alloc] initWithData:[myImageRep TIFFRepresentation]];

Aside from your primary question, don't do this.  Use -initWithSize: and then 
directly add the representation to the image using -addRepresentation:.


> So now I have an NSImage. What happens if I delete/release myImageRep (my
> NSBitmapImageRep)?
> 
> Has the call to NSImage copied my pixels so that they are self-contained
> within the NSImage?

The general answer is you don't know and you shouldn't care.  It is the 
responsibility of the framework to do what's necessary.  It may have retained 
the image rep or retained some private NSData object that represented the 
pixels or copied the data or whatever.

The memory management conventions of Cocoa are designed to be local in nature.  
Generally, you do not need to know what other code is doing.  (Exceptions are 
documented.)  You only need to get your part correct, where you retain objects 
if you need to ensure they live beyond the current scope (if you don't already 
have an ownership reference to them, as from +alloc, -copy…, etc.) and you 
release ownership references after you're done with those objects.  You just 
assume that the other parts of the code follow the rules, too, and everything 
works.

You said "delete/release myImageRep".  That "delete" represents incorrect 
thinking on your part.  You only ever release your ownership reference to the 
object.  You can't know whether something else also has an ownership reference 
to it, so you can't know when the object is deleted/deallocated.


In this particular case, you're using -TIFFRepresentation which creates a data 
object of a TIFF image file format.  Since that's not the same format as the 
pixel data you stored via -bitmapData, it's very likely an independent object.  
Also, there's no reason for the image rep to keep any reference to it around.  
For example, you could modify the bitmap data some more and generate a new TIFF 
data object and that would be different from the first.  Surely, it's clear to 
you that such modifications to the bitmap data of the image rep must not modify 
the TIFF data that you created earlier.

Then, -initWithData: decodes the TIFF data and makes a new NSImage with 
whatever representations it needs.  Because of the layers of 
abstraction/conversion that the data went through, it's very unlikely that the 
new NSImage or representations have any references to the original image rep.

Regards,
Ken


___

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: NSImage from bitmap - then delete bitmap

[Graham Cox]

> On 22 Jul 2016, at 3:37 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
> I create an NSBitmapImageRep:
> 
> [[[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL
> pixelsWide:pixelSize.width
> pixelsHigh:pixelSize.height
> bitsPerSample:8
> samplesPerPixel:4
> hasAlpha:YES
> isPlanar:NO
> colorSpaceName:NSDeviceRGBColorSpace
> bitmapFormat:NSAlphaFirstBitmapFormat
> bytesPerRow:pixelSize.width * 4
> bitsPerPixel:32]
> 
> I then get the address by sending a "bitmapData" message to the object
> 
> After filling it with image data, I call:
> 
> NSImage* image =
> [[NSImage alloc] initWithData:[myImageRep TIFFRepresentation]];
> 
> So now I have an NSImage. What happens if I delete/release myImageRep (my
> NSBitmapImageRep)?

Nothing. The rep isn’t doing anything after this point; you can release it 
safely.

> Has the call to NSImage copied my pixels so that they are self-contained
> within the NSImage?

Yes.

But that’s not a great way to do this. You’ve made an image, you’ve encoded it 
as TIFF data, then you’ve made a new image, which has decoded the TIFF data to 
make a new image rep/bitmap.

You could just add the representation directly to a new NSImage (warning: typed 
into Mail, check method names):

NSImage* myImage = [[NSImage alloc] initWithSize:NSMakeSize(width,height)];

[myImage addRepresentation:theBitmapIMadeFirst];

[theBitmapIMadeFirst release];  // because NSImage retained it

…

done.



All NSImage is is a “box” in which a bunch of NSImageReps reside. It sometimes 
makes those reps itself from data, etc, but you can make them yourself and add 
them. It’s way more efficient.

—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

NSImage from bitmap - then delete bitmap

[Trygve Inda]

I create an NSBitmapImageRep:

[[[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL
pixelsWide:pixelSize.width
pixelsHigh:pixelSize.height
bitsPerSample:8
samplesPerPixel:4
hasAlpha:YES
isPlanar:NO
colorSpaceName:NSDeviceRGBColorSpace
bitmapFormat:NSAlphaFirstBitmapFormat
bytesPerRow:pixelSize.width * 4
bitsPerPixel:32]

I then get the address by sending a "bitmapData" message to the object

After filling it with image data, I call:

NSImage* image =
[[NSImage alloc] initWithData:[myImageRep TIFFRepresentation]];

So now I have an NSImage. What happens if I delete/release myImageRep (my
NSBitmapImageRep)?

Has the call to NSImage copied my pixels so that they are self-contained
within the NSImage?

If not, how can I do so? I am using a single NSBitmapImageRep and trying to
reuse it while making many different NSImage objects, each with their own
data.

Thanks,

Trygve



___

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: Generic Bitmap to NSImage

[Raglan T. Tiger]

 On Jun 25, 2015, at 5:32 PM, Ken Thomases k...@codeweavers.com wrote:
 
 First suggestion is to cache the results so you don't have to convert every 
 time.

This is the approach I have taken in conjunction with the other comments that 
showed I was copying things twice.

I have achieved the performance desired.

Thanks all.

-rags

___

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: Generic Bitmap to NSImage

[Graham Cox]

 On 26 Jun 2015, at 9:10 am, Raglan T. Tiger r...@crusaderrabbit.net wrote:
 
 I have a list of generic bitmaps that are to be transformed to NSImages.  The 
 list can be long, I haven limits on it.
 
 Here is the code I use to populate an NSMenu that gets set into an 
 NSPopUpButton.
 
 I need to speed this process up ... any suggestions?


Instead of creating a CGBitmapContext to wrap your pixel buffer, then turning 
it into a CGImage, then copying it to an NSImage, why not create a 
NSBitmapImageRep directly wrapping the original buffer? Then it can be added to 
an NSImage as a rep without any copying being necessary at any point. The 
slowness here (which you imply is a problem) is very likely due to the fact 
that you are having to copy each bitmap twice (once when you create the 
CGImage, the second time when you blit that into the NSImage).

—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

Generic Bitmap to NSImage

[Raglan T. Tiger]

I have a list of generic bitmaps that are to be transformed to NSImages.  The 
list can be long, I haven limits on it.

Here is the code I use to populate an NSMenu that gets set into an 
NSPopUpButton.

I need to speed this process up ... any suggestions?

NSMenu *comboMenu = [[[NSMenu alloc] init] autorelease];
   POSITION pos = listOfBBitmaps.GetHeadPosition();
while ( pos )
{
BBitmap *image = listOfBBitmaps.GetNext ( pos );

CGColorSpaceRef colorSpace;
colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB);
CGContextRefcontext;
context = CGBitmapContextCreate (image-m_array, image-m_pixelsx, 
image-m_pixelsy, 8, image-m_pixelsx * 4, colorSpace, 
kCGImageAlphaNoneSkipFirst|kCGBitmapByteOrder32Host);

CGImageRef cgImage = CGBitmapContextCreateImage (context);

CGContextRelease(context);
CGColorSpaceRelease(colorSpace);

size_t width = CGImageGetWidth( cgImage );
size_t height = CGImageGetHeight( cgImage );
NSRect imageRect = NSMakeRect(0, 0, width, height);
NSImage *nsImage = [[[NSImage alloc] initWithSize:imageRect.size] 
autorelease];
  
if ( [nsImage respondsToSelector:@selector(lockFocusFlipped:)] )
{
[nsImage lockFocusFlipped:YES];
}
else
{
[nsImage setFlipped:YES];
[nsImage lockFocus];
}
CGContextRef imageContext = (CGContextRef)[[NSGraphicsContext 
currentContext] graphicsPort];
CGContextDrawImage(imageContext, *(CGRect*)imageRect, cgImage);

[nsImage unlockFocus];

NSMenuItem *menuItem = [[[NSMenuItem alloc] init] autorelease];
[menuItem setImage: nsImage];

[menuItem setTitle:[NSString stringWithFormat:@untitled]];

[comboMenu addItem:menuItem];

m_imageCount++;

}





-rags



___

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: Generic Bitmap to NSImage

[Ken Thomases]

 On Jun 25, 2015, at 6:10 PM, Raglan T. Tiger r...@crusaderrabbit.net wrote:
 
 I have a list of generic bitmaps that are to be transformed to NSImages.  The 
 list can be long, I haven limits on it.
 
 Here is the code I use to populate an NSMenu that gets set into an 
 NSPopUpButton.
 
 I need to speed this process up ... any suggestions?
 
NSMenu *comboMenu = [[[NSMenu alloc] init] autorelease];
   POSITION pos = listOfBBitmaps.GetHeadPosition();
while ( pos )
{
BBitmap *image = listOfBBitmaps.GetNext ( pos );
 
CGColorSpaceRef colorSpace;
colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB);
CGContextRefcontext;
context = CGBitmapContextCreate (image-m_array, image-m_pixelsx, 
 image-m_pixelsy, 8, image-m_pixelsx * 4, colorSpace, 
 kCGImageAlphaNoneSkipFirst|kCGBitmapByteOrder32Host);
 
CGImageRef cgImage = CGBitmapContextCreateImage (context);
 
CGContextRelease(context);
CGColorSpaceRelease(colorSpace);
 
size_t width = CGImageGetWidth( cgImage );
size_t height = CGImageGetHeight( cgImage );
NSRect imageRect = NSMakeRect(0, 0, width, height);
NSImage *nsImage = [[[NSImage alloc] initWithSize:imageRect.size] 
 autorelease];
 
if ( [nsImage respondsToSelector:@selector(lockFocusFlipped:)] )
{
[nsImage lockFocusFlipped:YES];
}
else
{
[nsImage setFlipped:YES];
[nsImage lockFocus];
}
CGContextRef imageContext = (CGContextRef)[[NSGraphicsContext 
 currentContext] graphicsPort];
CGContextDrawImage(imageContext, *(CGRect*)imageRect, cgImage);
 
[nsImage unlockFocus];
 
NSMenuItem *menuItem = [[[NSMenuItem alloc] init] autorelease];
[menuItem setImage: nsImage];
 
[menuItem setTitle:[NSString stringWithFormat:@untitled]];
 
[comboMenu addItem:menuItem];
 
m_imageCount++;
 
}

First suggestion is to cache the results so you don't have to convert every 
time.

Second is to start the process in the background as soon as you think you'll 
need the images rather than doing it synchronously.

Third is to avoid using drawing to create the NSImage.  There are two separate 
approaches:

1) Create the image by creating an NSBitmapImageRep from the bitmap 
data and then creating an NSImage and adding that rep to it.  You would call 
-initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:
 to create the NSBitmapImageRep.  You would use -initWithSize: to create the 
NSImage.  You would add the image rep to the image using -addRepresentation:.

2) Create a CGImage using CGImageCreate().  Create an NSImage using 
-initWithCGImage:size:.

I doubt there's significant performance difference between the two methods, so 
choose whichever seems most natural.

Regards,
Ken


___

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: Drawing inside an NSImage?

[Markus Spoettl]

On 09/03/15 00:12, Patrick J. Collins wrote:

   [_image lockFocus];
   [[NSColor blueColor] set];
   NSBezierPath *line = [NSBezierPath bezierPath];

   NSPoint pointA = NSMakePoint(0, 0);
   NSPoint pointB = NSMakePoint(self.bounds.size.width, 0);

   [line moveToPoint:pointA];
   [line lineToPoint:pointB];
   [line stroke];

What am I doing wrong here?


If that's your real code, you need to call [_image unlockFocus] after you are 
done painting the content of the image to balance the call to -lockFocus.


Regards
Markus
--
__
Markus Spoettl
___

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

Drawing inside an NSImage?

[Patrick J. Collins]

I have an NSView which has in its drawRect: method:

NSColor *backgroundColor = [NSColor colorWithPatternImage:self.image];
[backgroundColor setFill];

...

the image method does:

  -(NSImage *)image {
  if (!_image) {
  _image = [[NSImage alloc] initWithSize:self.bounds.size];

  [_image lockFocus];
  [[NSColor blueColor] set];
  NSBezierPath *line = [NSBezierPath bezierPath];

  NSPoint pointA = NSMakePoint(0, 0);
  NSPoint pointB = NSMakePoint(self.bounds.size.width, 0);

  [line moveToPoint:pointA];
  [line lineToPoint:pointB];
  [line stroke];
  }
return _image;
  }

The resulting line is drawn off center (somewhere around -10px) from the middle
of the NSView...  I would like to have my 0,0 origin be the bottom left corner
of the NSView as I would get if I were to put this line directly in the
drawRect (not using an NSImage): method..

What am I doing wrong here?

Patrick J. Collins
http://collinatorstudios.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: Drawing inside an NSImage?

[Ken Thomases]

On Mar 8, 2015, at 6:12 PM, Patrick J. Collins patr...@collinatorstudios.com 
wrote:

 I have an NSView which has in its drawRect: method:
 
NSColor *backgroundColor = [NSColor colorWithPatternImage:self.image];
[backgroundColor setFill];
 
 ...
 
 the image method does:
 
  -(NSImage *)image {
  if (!_image) {
  _image = [[NSImage alloc] initWithSize:self.bounds.size];
 
  [_image lockFocus];
  [[NSColor blueColor] set];
  NSBezierPath *line = [NSBezierPath bezierPath];
 
  NSPoint pointA = NSMakePoint(0, 0);
  NSPoint pointB = NSMakePoint(self.bounds.size.width, 0);
 
  [line moveToPoint:pointA];
  [line lineToPoint:pointB];
  [line stroke];
  }
return _image;
  }
 
 The resulting line is drawn off center (somewhere around -10px) from the 
 middle
 of the NSView...  I would like to have my 0,0 origin be the bottom left corner
 of the NSView as I would get if I were to put this line directly in the
 drawRect (not using an NSImage): method..
 
 What am I doing wrong here?

The drawing of a pattern is governed by the graphics context's patternPhase.  
In your view's -drawRect:, you may need to do [NSGraphicsContext 
currentContext].patternPhase = NSZeroPoint.  Or possibly, it may need to be set 
to the view's origin in window coordinates ([self 
convertPoint:self.frame.origin toView:nil]).

Also, you only create the image once, the first time it is requested.  The 
image's size is fixed to the view's bounds' size as it was at that time.  If 
the view changes size after that, the image size will no longer match the 
view's size unless you invalidate the cache so it is recreated the next time it 
is needed.

Regards,
Ken


___

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

Why use NSCustomImageRep for drawing in code in NSImage?

[Jerry Krinock]

I’m modernizing the old images on some buttons in an OS X app, replacing their 
.png resources with simple line art, drawn in code.  In so doing I stumbled 
across Daniel Jalkut’s old LittleYellowGuy demo [1], in which the drawing code 
is in the delegate of a NSCustomImageRep, which is added to an empty image.  
I’ve always done this instead by sending -lockFocus to an empty image and 
drawing directly into it.  For my purposes, is there any performance or other 
advantage to using the NSCustomImageRep intermediary?

Thank you,

Jerry

1.  http://www.red-sweater.com/blog/223/resolution-independent-fever
___

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: Why use NSCustomImageRep for drawing in code in NSImage?

[Ken Thomases]

On Dec 14, 2014, at 8:53 PM, Jerry Krinock je...@ieee.org wrote:

 I’m modernizing the old images on some buttons in an OS X app, replacing 
 their .png resources with simple line art, drawn in code.  In so doing I 
 stumbled across Daniel Jalkut’s old LittleYellowGuy demo [1], in which the 
 drawing code is in the delegate of a NSCustomImageRep, which is added to an 
 empty image.  I’ve always done this instead by sending -lockFocus to an empty 
 image and drawing directly into it.  For my purposes, is there any 
 performance or other advantage to using the NSCustomImageRep intermediary?

The article makes it fairly clear that it's about resolution independence.

Apple's recommendation is to use +[NSImage 
imageWithSize:flipped:drawingHandler:].  That creates and manages the 
NSCustomImageRep under the hood.
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW32

Regards,
Ken


___

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: Why use NSCustomImageRep for drawing in code in NSImage?

[Jerry Krinock]

Thank you for the exact link to that section of Apple documentation, Ken.  I’d 
noticed those new block-based drawing methods, but not the warning that If you 
use the lock focus methods for drawing, you can get unexpected results…”

Well, I’m long overdue on pulling the plug on users of 10.7 and earlier.  Looks 
like it’s time to fix that.


___

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: NSImage glowing

[Uli Kusterer]

On 04 Nov 2014, at 19:41, Alex Kac a...@webis.net wrote:
 I have an NSImage that looks like  in a mini-toolbar - kind of like Xcode. 
 
 Now of course I can just create a hand-drawn selected version, but I like 
 doing things like that in code. So I’d like to have code that takes the 
 NSImage and makes it glow like Xcode here:
 https://www.dropbox.com/s/by642iw7xosnki7/Screenshot%202014-11-04%2011.40.18.png?dl=0

 OK, so that’s not actually a glow, you’re just trying to tint an image in a 
different color, it seems? I presume your image is a flat 2D glyph like Xcode’s 
as well?

 You will want to look into the compositing modes that Quartz supports (or 
rather, NSImage in its drawing calls). I’ve done this a couple of times. There 
is one of these modes, but I forget which … maybe SourceIn? DestinationIn? One 
of those, that essentially uses the alpha from your NSImage to obliterate the 
alpha of the destination image you’re drawing on top. So what you do is create 
an NSImage, lockFocus, fill it with the desired color, then SourceIn or 
whatever the actual image.

 Alternatively, if you have an NSButton, you can use a PDF image and use 
NSImage’s template image mechanism (I think you just name it 
xxxTemplateImage.pdf) and then one of NSButton's highlighting styles will 
recognize it’s a template image and fill and bezel it. This depends on what 
style of button you’re using, too, though, so may be rather limiting.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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: NSImage glowing

[Allan Odgaard]

On 11 Nov 2014, at 12:18, Uli Kusterer wrote:

Now of course I can just create a hand-drawn selected version, but I 
like doing things like that in code. So I’d like to have code that 
takes the NSImage and makes it glow like Xcode here:

https://www.dropbox.com/s/by642iw7xosnki7/Screenshot%202014-11-04%2011.40.18.png?dl=0


OK, so that’s not actually a glow, you’re just trying to tint an 
image in a different color, it seems? I presume your image is a flat 
2D glyph like Xcode’s as well?


You will want to look into the compositing modes that Quartz supports 
[…]


This code should draw a monochrome `srcImage` (with alpha) at `dstRect` 
in blue:


NSImage* srcImage = …;
NSRect dstRect = …;

// Save graphics state since we’ll install a clipping mask
[NSGraphicsContext saveGraphicsState];

// Setup a mask based on our image
	CGImageRef cgImage = [srcImage CGImageForProposedRect:dstRect 
context:[NSGraphicsContext currentContext] hints:nil];
	CGContextClipToMask((CGContextRef)[[NSGraphicsContext currentContext] 
graphicsPort], dstRect, cgImage);


[[NSColor blueColor] set];
NSRectFillUsingOperation(dstRect, NSCompositeSourceOver);

// Restore graphics state (without the clipping mask)
[NSGraphicsContext restoreGraphicsState];

___

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: NSImage glowing

[Alex Kac]

Thank you guys. This has helped a lot. I have a much better understanding of 
this now.

 On Nov 5, 2014, at 7:40 PM, Lee Ann Rucker lruc...@vmware.com wrote:
 
 
 On Nov 5, 2014, at 5:53 PM, Wim Lewis w...@omnigroup.com wrote:
 
 
 On Nov 5, 2014, at 3:43 PM, Alex Kac a...@webis.net wrote:
 BUT, in this case I’m just trying to get the glow on selected images, so 
 when I look at the code below all I see is that we’re getting the bitmap 
 and drawing it. I’m not understanding how that gets a glow.
 
 
 It’s applied by NSButtonCell, which knows that if it’s in the selected state 
 and its image is marked as a template image (or some set of conditions like 
 that), then it should apply the glow when drawing.
 
 I take it you’re trying to get this effect in some place other than inside a 
 button? It’s not unreasonable to use an NSCell instance elsewhere— that’s 
 essentially what cells are for, to abstract away some of the drawing 
 behavior from the control view that uses them.
 
 I think NSButtonCell uses NSSetFocusRingStyle() to provide the actual 
 effect, but there may be additional magic in there.
 
 If it's the blue that toolbar buttons apply to template images, it's not 
 using that - I don't know what it is, but they were only fuzzy in the first 
 OS that used them, and even then they used something else. There's also an 
 etched effect it gets, depending on which OS you're in. I sent Alex a sample 
 app that puts everything together.
 
 But yes, for fuzzy blue around an icon, all you have to do is call 
 NSSetFocusRingStyle before drawing it. This doesn't change the icon colors, 
 though.
 ___
 
 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/alex%40webis.net
 
 This email sent to a...@webis.net

Alex Kac - President and Founder
Web Information Solutions, Inc.

I am not young enough to know everything.
--Oscar Wilde





___

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: NSImage glowing

[Alex Kac]

Yeah, I need to look at that original message. I’ve been doing iOS stuff for 
years and so OS X stuff is a bit foreign to me. I only hit the OS X stuff 
intermittently - i.e. when my team needs some specific UI stuff which is ironic 
in a way. We’re all iOS developers learning OS X.

So, can you help me understand what the below code does? So I have this class:

@interface MiniTabBarButton : NSButton

@property(strong) NSTabViewItem *tabViewItem;

@end

and we create the button:

NSImage* iconImage = [(id MiniTabBarItem)tabViewItem.identifier icon];
[iconImage setTemplate:YES];
newButton.image = iconImage;

So with that in mind, remember I don’t even really know what NSButton provides 
(again, I understand UIButtons really well - and I do have some understanding 
of NSButton custom drawing to some degree as I did write a subclass for the 
checkbox style:
@interface CalendarFilterCheckbox : NSButtonCell

BUT, in this case I’m just trying to get the glow on selected images, so when I 
look at the code below all I see is that we’re getting the bitmap and drawing 
it. I’m not understanding how that gets a glow.

Sorry for being dense, but I do learn quickly. I just am like a blind man at 
first.

 On Nov 4, 2014, at 12:48 PM, Lee Ann Rucker lruc...@vmware.com wrote:
 
 If you want the same blue highlight that NSButton applies to template images, 
 you can get the NSButtonCell to draw it into a graphics context and get an 
 image that way - I answered this when you asked about buttons specifically 
 back in June. (My bug requesting an NSImage method to do that is still open 
 and presumably unloved) Once you've got your buttonCell configured, do this:
 
 
   NSRect bounds = NSZeroRect;
   bounds.size = [template size];
 
   NSBitmapImageRep *bmpImageRep =
  [NSBitmapImageRep imageRepWithSize:bounds.size scale:scale]; // Utility 
 wrapper around imageRepWith32bitBuffer
 
   [NSGraphicsContext saveGraphicsState];
   NSGraphicsContext *bitmapContext =
  [NSGraphicsContext graphicsContextWithBitmapImageRep:bmpImageRep];
   [NSGraphicsContext setCurrentContext:bitmapContext];
 
   [buttonCell drawImage:template withFrame:bounds inView:nil];
 
   [NSGraphicsContext restoreGraphicsState];
   return bmpImageRep;
 
 
 On Nov 4, 2014, at 10:41 AM, Alex Kac a...@webis.net wrote:
 
 I have an NSImage that looks like  in a mini-toolbar - kind of like Xcode. 
 
 Now of course I can just create a hand-drawn selected version, but I like 
 doing things like that in code. So I’d like to have code that takes the 
 NSImage and makes it glow like Xcode here:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dropbox.com_s_by642iw7xosnki7_Screenshot-25202014-2D11-2D04-252011.40.18.png-3Fdl-3D0d=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=ie7S-J__EKnfyVOBV7-jV2rZ--p47O6vkyTklpDM3h4m=lUNK2PEwQXtoqjBGMWU6Y3iSwSvLFO0mx-2wI6kiSNgs=PSrnj94BQRWKM8dFv5gi7Tz3a3NH1_5gmiUvJHsFfP4e=
  
 
 I’ve Googled this and I see a bunch of stuff, that I can’t get working at 
 all. Most articles were for iOS and some repsonders even said “if I was 
 using an NSImage, this would be easy - but for iOS you do…”. 
 
 So… can anyone point me to the right place?
 
 ___
 
 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_cocoa-2Ddev_lrucker-2540vmware.comd=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=ie7S-J__EKnfyVOBV7-jV2rZ--p47O6vkyTklpDM3h4m=lUNK2PEwQXtoqjBGMWU6Y3iSwSvLFO0mx-2wI6kiSNgs=QsN7f2Wy2w3J4nIWtViq9WfFRo-Fwf46hQqveR8coB0e=
  
 
 This email sent to lruc...@vmware.com
 

Alex Kac - President and Founder
Web Information Solutions, Inc.
To educate a person in mind and not in morals is to educate a menace to 
society.
-- Theodore Roosevelt







___

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: NSImage glowing

[Wim Lewis]

On Nov 5, 2014, at 3:43 PM, Alex Kac a...@webis.net wrote:
 BUT, in this case I’m just trying to get the glow on selected images, so when 
 I look at the code below all I see is that we’re getting the bitmap and 
 drawing it. I’m not understanding how that gets a glow.


It’s applied by NSButtonCell, which knows that if it’s in the selected state 
and its image is marked as a template image (or some set of conditions like 
that), then it should apply the glow when drawing.

I take it you’re trying to get this effect in some place other than inside a 
button? It’s not unreasonable to use an NSCell instance elsewhere— that’s 
essentially what cells are for, to abstract away some of the drawing behavior 
from the control view that uses them.

I think NSButtonCell uses NSSetFocusRingStyle() to provide the actual effect, 
but there may be additional magic in there.


___

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: NSImage glowing

[Lee Ann Rucker]

On Nov 5, 2014, at 5:53 PM, Wim Lewis w...@omnigroup.com wrote:

 
 On Nov 5, 2014, at 3:43 PM, Alex Kac a...@webis.net wrote:
 BUT, in this case I’m just trying to get the glow on selected images, so 
 when I look at the code below all I see is that we’re getting the bitmap and 
 drawing it. I’m not understanding how that gets a glow.
 
 
 It’s applied by NSButtonCell, which knows that if it’s in the selected state 
 and its image is marked as a template image (or some set of conditions like 
 that), then it should apply the glow when drawing.
 
 I take it you’re trying to get this effect in some place other than inside a 
 button? It’s not unreasonable to use an NSCell instance elsewhere— that’s 
 essentially what cells are for, to abstract away some of the drawing behavior 
 from the control view that uses them.
 
 I think NSButtonCell uses NSSetFocusRingStyle() to provide the actual effect, 
 but there may be additional magic in there.

If it's the blue that toolbar buttons apply to template images, it's not using 
that - I don't know what it is, but they were only fuzzy in the first OS that 
used them, and even then they used something else. There's also an etched 
effect it gets, depending on which OS you're in. I sent Alex a sample app that 
puts everything together.

But yes, for fuzzy blue around an icon, all you have to do is call 
NSSetFocusRingStyle before drawing it. This doesn't change the icon colors, 
though.
___

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

NSImage glowing

[Alex Kac]

I have an NSImage that looks like  in a mini-toolbar - kind of like Xcode. 

Now of course I can just create a hand-drawn selected version, but I like doing 
things like that in code. So I’d like to have code that takes the NSImage and 
makes it glow like Xcode here:
https://www.dropbox.com/s/by642iw7xosnki7/Screenshot%202014-11-04%2011.40.18.png?dl=0

I’ve Googled this and I see a bunch of stuff, that I can’t get working at all. 
Most articles were for iOS and some repsonders even said “if I was using an 
NSImage, this would be easy - but for iOS you do…”. 

So… can anyone point me to the right place?

___

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: NSImage glowing

[Alex Zavatone]

I can't see the image, but what about a gaussian blur on a white outline of the 
icon with a 20% white UIColor on the background with a 5 pixel blur radius?

Dropbox is blocked from my current location

Sent from my iPad. Please pardon typos.

On Nov 4, 2014, at 1:41 PM, Alex Kac a...@webis.net wrote:

 I have an NSImage that looks like  in a mini-toolbar - kind of like Xcode. 
 
 Now of course I can just create a hand-drawn selected version, but I like 
 doing things like that in code. So I’d like to have code that takes the 
 NSImage and makes it glow like Xcode here:
 https://www.dropbox.com/s/by642iw7xosnki7/Screenshot%202014-11-04%2011.40.18.png?dl=0
 
 I’ve Googled this and I see a bunch of stuff, that I can’t get working at 
 all. Most articles were for iOS and some repsonders even said “if I was using 
 an NSImage, this would be easy - but for iOS you do…”. 
 
 So… can anyone point me to the right place?
 
 ___
 
 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/zav%40mac.com
 
 This email sent to z...@mac.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: NSImage glowing

[Lee Ann Rucker]

If you want the same blue highlight that NSButton applies to template images, 
you can get the NSButtonCell to draw it into a graphics context and get an 
image that way - I answered this when you asked about buttons specifically back 
in June. (My bug requesting an NSImage method to do that is still open and 
presumably unloved) Once you've got your buttonCell configured, do this:


   NSRect bounds = NSZeroRect;
   bounds.size = [template size];

   NSBitmapImageRep *bmpImageRep =
  [NSBitmapImageRep imageRepWithSize:bounds.size scale:scale]; // Utility 
wrapper around imageRepWith32bitBuffer

   [NSGraphicsContext saveGraphicsState];
   NSGraphicsContext *bitmapContext =
  [NSGraphicsContext graphicsContextWithBitmapImageRep:bmpImageRep];
   [NSGraphicsContext setCurrentContext:bitmapContext];

   [buttonCell drawImage:template withFrame:bounds inView:nil];

   [NSGraphicsContext restoreGraphicsState];
   return bmpImageRep;


On Nov 4, 2014, at 10:41 AM, Alex Kac a...@webis.net wrote:

 I have an NSImage that looks like  in a mini-toolbar - kind of like Xcode. 
 
 Now of course I can just create a hand-drawn selected version, but I like 
 doing things like that in code. So I’d like to have code that takes the 
 NSImage and makes it glow like Xcode here:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dropbox.com_s_by642iw7xosnki7_Screenshot-25202014-2D11-2D04-252011.40.18.png-3Fdl-3D0d=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=ie7S-J__EKnfyVOBV7-jV2rZ--p47O6vkyTklpDM3h4m=lUNK2PEwQXtoqjBGMWU6Y3iSwSvLFO0mx-2wI6kiSNgs=PSrnj94BQRWKM8dFv5gi7Tz3a3NH1_5gmiUvJHsFfP4e=
  
 
 I’ve Googled this and I see a bunch of stuff, that I can’t get working at 
 all. Most articles were for iOS and some repsonders even said “if I was using 
 an NSImage, this would be easy - but for iOS you do…”. 
 
 So… can anyone point me to the right place?
 
 ___
 
 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_cocoa-2Ddev_lrucker-2540vmware.comd=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=ie7S-J__EKnfyVOBV7-jV2rZ--p47O6vkyTklpDM3h4m=lUNK2PEwQXtoqjBGMWU6Y3iSwSvLFO0mx-2wI6kiSNgs=QsN7f2Wy2w3J4nIWtViq9WfFRo-Fwf46hQqveR8coB0e=
  
 
 This email sent to lruc...@vmware.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: Scaling an NSImage to have exact pixel dimensions

[Graham Cox]

On 10 Oct 2014, at 3:57 pm, Carl Hoefs newsli...@autonomy.caltech.edu wrote:

 If there’s a cleaner way, please let me know!


// ... set up destination context ...


[[NSGraphicsContext currentContext] setImageInterpolation: 
NSImageInterpolationHigh];
[sourceImage drawInRect:dest fromRect:NSZeroRect operation:NSCompositeCopy 
fraction:1.0 respectFlipped:YES hints:nil];

// ... clean up leaving NSBitMapImageRep alone...

NSData* imageData = [destBitMapRep representationUsingType:... properties:...];




--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: Scaling an NSImage to have exact pixel dimensions

[Carl Hoefs]

On Oct 10, 2014, at 1:02 AM, Graham Cox graham@bigpond.com wrote:
 
 // ... set up destination context ...
 
 [[NSGraphicsContext currentContext] setImageInterpolation: 
 NSImageInterpolationHigh];
 [sourceImage drawInRect:dest fromRect:NSZeroRect operation:NSCompositeCopy 
 fraction:1.0 respectFlipped:YES hints:nil];
 
 // ... clean up leaving NSBitMapImageRep alone...
 
 NSData* imageData = [destBitMapRep representationUsingType:... properties:…];

Thanks Graham and Ken! You’re right, no need at all for the CIImage (flail) 
step. Here’s my cleaned-up code, combining both your inputs, works perfectly. 
Anything still superfluous here? 
-Carl

. . .
NSRect imgRect = NSMakeRect(0.0, 0.0, 640.0, 480.0);
NSBitmapImageRep *offscreenRep = [[NSBitmapImageRep alloc]
   initWithBitmapDataPlanes:NULL
 
pixelsWide:imgRect.size.width
 
pixelsHigh:imgRect.size.height
  bitsPerSample:8
samplesPerPixel:4
   hasAlpha:YES
   isPlanar:NO
 
colorSpaceName:NSDeviceRGBColorSpace
   
bitmapFormat:NSAlphaFirstBitmapFormat
bytesPerRow:0
   bitsPerPixel:32];
NSGraphicsContext *gc = [NSGraphicsContext 
graphicsContextWithBitmapImageRep:offscreenRep];
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:gc];
[[NSGraphicsContext currentContext] setImageInterpolation: 
NSImageInterpolationHigh];
[srcImage drawInRect:imgRect fromRect:NSZeroRect operation:NSCompositeCopy 
fraction:1.0 respectFlipped:YES hints:nil];
[NSGraphicsContext restoreGraphicsState];
NSData *dataObj = [offscreenRep representationUsingType:NSJPEGFileType 
properties:nil];
. . .

* Final NSImage: NSImage 0x60873f80 Size={640, 480} Reps=(
NSBitmapImageRep 0x608a9d20 Size={640, 480} ColorSpace=(not yet 
loaded) BPS=8 BPP=(not yet loaded) Pixels=640x480 Alpha=NO Planar=NO 
Format=(not yet loaded) CurrentBacking=nil (faulting) 
CGImageSource=0x60800016e700
)


___

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

Scaling an NSImage to have exact pixel dimensions

[Carl Hoefs]

OS X 10.9

I need to scale an NSImage's dimensions to exactly 640x480 pixels before 
sending it remotely for processing. If I use NSImage's -setSize:(NSSize) 
method, it does set the size - temporarily. If I then try to serialize that 
NSImage into an NSData for transfer, that resize information seems to get lost:

NSImage *oldImage = [[NSImage alloc] initWithContentsOfFile:myFilename];
[oldImage setSize:NSMakeSize(640.0,480.0)];
NSLog(@Old Image: %@,oldImage);

NSData *dataObj = [oldImage 
TIFFRepresentationUsingCompression:NSTIFFCompressionLZW factor:1.0 ];
NSImage *newImage = [[NSImage alloc ] initWithData:dataObj];
NSLog(@New Image: %@,newImage);


* Old Image: NSImage 0x618000267840 Size={640, 480} Reps=(
NSBitmapImageRep 0x6180002a4320 Size={1670, 1200} ColorSpace=(not yet 
loaded) BPS=8 BPP=(not yet loaded) Pixels=1670x1200 Alpha=NO Planar=NO 
Format=(not yet loaded) CurrentBacking=nil (faulting) 
CGImageSource=0x61800016b700
)

 * New Image: NSImage 0x61873e00 Size={1670, 1200} Reps=(
NSBitmapImageRep 0x618b4700 Size={1670, 1200} ColorSpace=(not yet 
loaded) BPS=8 BPP=(not yet loaded) Pixels=1670x1200 Alpha=NO Planar=NO 
Format=(not yet loaded) CurrentBacking=nil (faulting) 
CGImageSource=0x61800017e240
)

What is the correct way to do this?
-Carl


___

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: Scaling an NSImage to have exact pixel dimensions

[Ken Thomases]

On Oct 9, 2014, at 9:08 PM, Carl Hoefs newsli...@autonomy.caltech.edu wrote:

 I need to scale an NSImage's dimensions to exactly 640x480 pixels before 
 sending it remotely for processing.

 What is the correct way to do this?

Create an NSBitmapImageRep with the appropriate properties.  Create an 
NSGraphicsContext from that bitmap image rep using +[NSGraphicsContext 
graphicsContextWithBitmapImageRep:].  Make that graphics context current.  Draw 
the image.  Flush and restore the graphics context.  Get the data from the 
bitmap image rep in an image file format using 
-representationUsingType:properties: or (if you really want TIFF) 
-TIFFRepresentationUsingCompression:factor:.

Regards,
Ken


___

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: Scaling an NSImage to have exact pixel dimensions

[Graham Cox]

On 10 Oct 2014, at 1:08 pm, Carl Hoefs newsli...@autonomy.caltech.edu wrote:

  [oldImage setSize:NSMakeSize(640.0,480.0)];


The size of an NSImage is an abstract property that does not reflect the pixel 
dimensions of the representations within it. This sounds a bit odd, until you 
realise that images can have any resolution (including none, for PDFs), so this 
size is the size the image scales to, in points, when drawn in a Quartz context.

Instead you need to work with the bitmap image representation that the image 
holds (or create one if it doesn't have one). In fact this latter approach 
might be the most general and safest anyway, so you can work with PDF images, 
etc.

--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: Scaling an NSImage to have exact pixel dimensions

[Carl Hoefs]

On Oct 9, 2014, at 8:05 PM, Ken Thomases k...@codeweavers.com wrote:

 On Oct 9, 2014, at 9:08 PM, Carl Hoefs newsli...@autonomy.caltech.edu wrote:
 
 I need to scale an NSImage's dimensions to exactly 640x480 pixels before 
 sending it remotely for processing.
 
 What is the correct way to do this?
 
 Create an NSBitmapImageRep with the appropriate properties.  Create an 
 NSGraphicsContext from that bitmap image rep using +[NSGraphicsContext 
 graphicsContextWithBitmapImageRep:].  Make that graphics context current.  
 Draw the image.  Flush and restore the graphics context.  Get the data from 
 the bitmap image rep in an image file format using 
 -representationUsingType:properties: or (if you really want TIFF) 
 -TIFFRepresentationUsingCompression:factor:.

Awesome pointers, I got it to work! The tricky part was the actual scaling. It 
would crop but not scale, so resorted to using CIImage. If there’s a cleaner 
way, please let me know!

NSRect imgRect = NSMakeRect(0.0, 0.0, 640.0, 480.0);
NSSize imgSize = imgRect.size;
NSBitmapImageRep *offscreenRep = [[NSBitmapImageRep alloc]
   initWithBitmapDataPlanes:NULL
 pixelsWide:imgSize.width
 pixelsHigh:imgSize.height
  bitsPerSample:8
samplesPerPixel:4
   hasAlpha:YES
   isPlanar:NO
 
colorSpaceName:NSDeviceRGBColorSpace
   
bitmapFormat:NSAlphaFirstBitmapFormat

bytesPerRow:8*4*imgSize.width
   bitsPerPixel:32];
// set offscreen context
NSGraphicsContext *gc = [NSGraphicsContext 
graphicsContextWithBitmapImageRep:offscreenRep];
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:gc];

// scale the image from cgRect down to imgRect
CIImage *ciImage = [CIImage imageWithData:dataObj];
CGRect cgRect = [ciImage extent];
[[gc CIContext] drawImage:ciImage inRect:imgRect fromRect:cgRect];

// reset the current context
[NSGraphicsContext restoreGraphicsState];

// create an NSImage and add the rep to it
NSImage *img = [[NSImage alloc] initWithSize:imgSize];
[img addRepresentation:offscreenRep];
NSLog(@* Final Image: %@,img);


* Final Image: NSImage 0x608000276c80 Size={640, 480} Reps=(
NSBitmapImageRep 0x608b6b00 Size={640, 480} ColorSpace=(not yet 
loaded) BPS=8 BPP=(not yet loaded) Pixels=640x480 Alpha=NO Planar=NO 
Format=(not yet loaded) CurrentBacking=nil (faulting) 
CGImageSource=0x608000167200
)

Thanks again!
-Carl


___

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: Scaling an NSImage to have exact pixel dimensions

[Ken Thomases]

On Oct 9, 2014, at 11:57 PM, Carl Hoefs newsli...@autonomy.caltech.edu wrote:

 On Oct 9, 2014, at 8:05 PM, Ken Thomases k...@codeweavers.com wrote:
 
 Create an NSBitmapImageRep with the appropriate properties.  Create an 
 NSGraphicsContext from that bitmap image rep using +[NSGraphicsContext 
 graphicsContextWithBitmapImageRep:].  Make that graphics context current.  
 Draw the image.  Flush and restore the graphics context.  Get the data from 
 the bitmap image rep in an image file format using 
 -representationUsingType:properties: or (if you really want TIFF) 
 -TIFFRepresentationUsingCompression:factor:.
 
 Awesome pointers, I got it to work! The tricky part was the actual scaling. 
 It would crop but not scale, so resorted to using CIImage. If there’s a 
 cleaner way, please let me know!

What did you try?  If you are starting with an NSImage, you can just draw it 
using one of the -drawInRect:… methods.

NSRect imgRect = NSMakeRect(0.0, 0.0, 640.0, 480.0);
NSSize imgSize = imgRect.size;
NSBitmapImageRep *offscreenRep = [[NSBitmapImageRep alloc]
   initWithBitmapDataPlanes:NULL
 pixelsWide:imgSize.width
 pixelsHigh:imgSize.height
  bitsPerSample:8
samplesPerPixel:4
   hasAlpha:YES
   isPlanar:NO
 
 colorSpaceName:NSDeviceRGBColorSpace
   
 bitmapFormat:NSAlphaFirstBitmapFormat

 bytesPerRow:8*4*imgSize.width

I recommend that you pass 0 for bytesPerRow.  This lets the system optimize the 
buffer alignment.  (It's also one less thing to get wrong.)

   bitsPerPixel:32];
// set offscreen context
NSGraphicsContext *gc = [NSGraphicsContext 
 graphicsContextWithBitmapImageRep:offscreenRep];
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:gc];
 
// scale the image from cgRect down to imgRect
CIImage *ciImage = [CIImage imageWithData:dataObj];
CGRect cgRect = [ciImage extent];
[[gc CIContext] drawImage:ciImage inRect:imgRect fromRect:cgRect];
 
// reset the current context
[NSGraphicsContext restoreGraphicsState];
 
// create an NSImage and add the rep to it
NSImage *img = [[NSImage alloc] initWithSize:imgSize];
[img addRepresentation:offscreenRep];
NSLog(@* Final Image: %@,img);

Why did you create an NSImage?  Just for testing?  I was under the impression 
that you wanted image-file-format data.

 Thanks again!

You're welcome.  I'm glad I could help.

Cheers,
Ken


___

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

Transparent NSImage in NSButton

[Aandi Inston]

I'm wondering what the right way is to use transparent images in an
NSButton (not using Interface Builder as this is a port of a platform
independent dialog library, which is also required to work back to 10.5).
Transparent images here = PDF loaded as NSImage which do not paint their
entire canvas.

These NSButton elements sit in an NSWindow with default background Color.
The problems:
- sometimes (as yet unclear when but it might have started when we started
to set image scaling) the first paint of the image has a
white background.
- subsequent repaints (e.g. when the button is clicked) repaint on the
window's background, i.e. seemingly as required
- each subsequent repaint does not clear the background. This results in
repeated clicks making the image darker and darker, or if there is an
alternate image we are left with the shadow of both.

Key definitions
- NSButton setImagePosition:NSImageOnly setBordered:no and
[[button cell] setImageScaling:NSImageScaleProportionallyUpOrDown]
- For a single image, NSButton setImageType:NSMomentaryLightButton
- For two image, NSButton setImageType:NSToggleButton or
NSMomentaryChangeButton

I'm wondering if I need to add code that causes the button area to be
erased or repainted in the background colour before it is painted. Or
perhaps use a different control/view type altogether (NSImageView?) and
mandate non-transparent images where button functionality is actually
needed.

Thanks in advance.
___

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

ImageIO errors generating UIImage from NSData from NSImage

[Carl Hoefs]

OS X 10.8.5, iOS 7.1.2
I have an OSX app that shows NSImages. When the user selects an image, it is 
transferred to an iOS device as an NSData and then turned into a UIImage and 
displayed onscreen.

The problem is I can't get the conversion of NSImage to NSData to UIImage to 
work. I'm using a home-brew -nsDataFromNSImage: method (attached below) for the 
conversion:

NSData *imageData = [self nsDataFromNSImage:nsImage];

On the iOS side, when I try to recreate a UIImage from the NSData, like this:

UIImage *userImage = [UIImage imageWithData:imageData];

-imageWithData: generates odd messages and returns NULL.

Error: ImageIO: PNG PNG unsigned integer out of range
Error: ImageIO: PNG [00][00][00][00]: invalid chunk type
Error: ImageIO: PNG [DA][AD][F9][1A]: invalid chunk type
Error: ImageIO: PNG [07][82]o[ED]: invalid chunk type
Error: ImageIO: PNG invalid distance too far back

Is there another way of doing this? I've also tried the method here without 
success https://lists.apple.com/archives/cocoa-dev/2011/Aug/msg01102.html
-Carl



- (NSData *) nsDataFromNSImage:(NSImage *) nsImage
{
NSBitmapImageRep *imageRep = 
[NSBitmapImageRep imageRepWithData:[nsImage TIFFRepresentation]];
return [imageRep representationUsingType:NSPNGFileType
  properties:nil];
}
___

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: ImageIO errors generating UIImage from NSData from NSImage

[Jens Alfke]

On Jul 9, 2014, at 11:13 AM, Carl Hoefs newsli...@autonomy.caltech.edu wrote:

 -imageWithData: generates odd messages and returns NULL.
 Error: ImageIO: PNG PNG unsigned integer out of range
 Error: ImageIO: PNG [00][00][00][00]: invalid chunk type

I don’t think this is an image decoding issue. I think the problem is that your 
data is getting mangled coming over the wire. Especially since you were 
reporting problems with the network I/O earlier.

—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: ImageIO errors generating UIImage from NSData from NSImage

[Carl Hoefs]

On Jul 9, 2014, at 1:29 PM, Jens Alfke j...@mooseyard.com wrote:
 
 On Jul 9, 2014, at 11:13 AM, Carl Hoefs newsli...@autonomy.caltech.edu 
 wrote:
 
 -imageWithData: generates odd messages and returns NULL.
 Error: ImageIO: PNG PNG unsigned integer out of range
 Error: ImageIO: PNG [00][00][00][00]: invalid chunk type
 
 I don’t think this is an image decoding issue. I think the problem is that 
 your data is getting mangled coming over the wire. Especially since you were 
 reporting problems with the network I/O earlier.
 
 —Jens

Agreed. I'm now in the process of verifying checksums on both sides… Might have 
to resort to sending Base64 strings...
-Carl

___

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

IOBluetoothDeviceSelectorController and NSImage compositeToPoint

[Livio Isaia]

Hi all,

I have

IOBluetoothDeviceSelectorController *deviceSelector;

when I call (self is NSObject NSApplicationDelegate)

[deviceSelector beginSheetModalForWindow:[self window] modalDelegate:self 
didEndSelector:@selector(browseEnd: returnCode: contextInfo:) contextInfo:NULL]

in the output window appears

*** WARNING: -[NSImage compositeToPoint:fromRect:operation:fraction:] is 
deprecated in MacOSX 10.8 and later. Please use -[NSImage 
drawAtPoint:fromRect:operation:fraction:] instead.

does anybody know what I can do to avoid this? I think I’ve installed the 
latest xcode sdk...

OSX 10.9.1, xcode 5.0.2

Thanks to all in advance,
regards,
livio

___

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: IOBluetoothDeviceSelectorController and NSImage compositeToPoint

[Fritz Anderson]

On 21 Jan 2014, at 3:52 AM, Livio Isaia lis...@tiscalinet.it wrote:

 when I call (self is NSObject NSApplicationDelegate)
 
 [deviceSelector beginSheetModalForWindow:[self window] modalDelegate:self 
 didEndSelector:@selector(browseEnd: returnCode: contextInfo:) 
 contextInfo:NULL]
 
 in the output window appears
 
 *** WARNING: -[NSImage compositeToPoint:fromRect:operation:fraction:] is 
 deprecated in MacOSX 10.8 and later. Please use -[NSImage 
 drawAtPoint:fromRect:operation:fraction:] instead.
 
 does anybody know what I can do to avoid this? I think I’ve installed the 
 latest xcode sdk...

I don’t have the whole story, but some system APIs emit warnings like that 
routinely. If your audit of your code convinces you you are passing the proper 
arguments, and the method works properly, you can ignore them. It’s Apple’s 
problem, and Apple will correct it before it affects your applications.

— F


___

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