On Nov 29, 2009, at 10:01 PM, John Horigan wrote: > > On Nov 29, 2009, at 9:09 PM, Graham Cox wrote: > >> >> On 30/11/2009, at 2:44 PM, Glenn McCord wrote: >> >>> What I'm expecting is the drawAtPoint method to draw nsString inside >>> the bitmapRep of the NSContext at which point I can retrieve the raw >>> data and do something with it. On account of the data all being zero, >>> I'm obviously doing something wrong and would really appreciate some >>> advice. >> >> >> You also have to lock focus on the bitmap, which requires that it first be >> added to an NSImage (I think if you are targeting 10.6 only there is a new >> API that means you can avoid this).
The OP was creating an NSGraphicsContext and making it the current drawing context, so I don't see a need to muck around with NSImage. The docs do say that you should only use -[NSString drawAtPoint:attributes:] when an NSView has focus, though. I know I've used -[NSString drawWithRect:options:attributes:] to draw to a bitmap context, so I'd give that a try (and be wary of the origin and flippedness of the context). >> Also, it's not necessary to allocate the bitmap's buffer - if you don't pass >> one, it will allocate it for you. >> >> --Graham >> > > Indeed, the initWithBitmapDataPlanes method treats the supplied buffer as > immutable and creates its own internal copy. This is not correct. From the docs [1]: "If planes is not NULL and the array contains at least one data pointer, the returned object will only reference the image data; it will not copy it. The object treats the image data in the buffers as immutable and will not attempt to alter it. When the object itself is freed, it will not attempt to free the buffers." Because of this, it's generally easier to let NSBitmapImageRep create the buffer for you, at least if you're going to be keeping it around. > You must request the bitmap back from the NSBitmapImageRep using the > bitmapData method. Prior to 10.6 the data backing up the NSBitmapImageRep was > a bitmap plane but in 10.6 the cocoa team changed the backing data for > NSBitmapImageRep to a CGImage. Either way, you should treat the data returned > by bitmapData as read-only (in case you were thinking of modifying it). My understanding is that this only applies if you create the bitmap rep with initWithCGImage: (which is an odd limitation to keep track of). You can still modify bitmap data from ordinary NSBitmapImageRep instances, but it will be slow since NSBitmapImageRep has to recache. Of course, this is just my interpretation of the release notes [2] so I'd be interested in information to the contrary. [1] http://developer.apple.com/mac/library/documentation/cocoa/Reference/ApplicationKit/Classes/NSBitmapImageRep_Class/Reference/Reference.html#//apple_ref/occ/instm/NSBitmapImageRep/initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: [2] http://developer.apple.com/mac/library/releasenotes/cocoa/AppKit.html
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
