Re: Is this a bug in Tiger's NSBitmapImageRep?
Re: Is this a bug in Tiger's NSBitmapImageRep?
- Subject: Re: Is this a bug in Tiger's NSBitmapImageRep?
- From: Cameron Hayne <email@hidden>
- Date: Tue, 3 May 2005 02:34:46 -0400
On 3-May-05, at 2:03 AM, Marc Liyanage wrote:
On 03.05.2005, at 03:31, Andrew Platzer wrote:
This is a change to the semantics of -initWithBitmapDataPlanes:...
Wow - this was just-in-time information for me as I was just about to
recompile my Ising simulation app on Tiger for the first time. I use
NSBitMapImageRep for fast display of the state of the (often hundreds
of millions of) "spins". Most of the time my NSBitMapImageRep's have
widths that are multiples of 32 (= sizeof(unsigned int) ) but some
auxiliary displays have widths as small as 5.
The following is what the docs say about this method. Isn't this
incorrect now?
If rowBytes is 0, the NSBitmapImageRep assumes there’s no empty
space at the end of a row.
Should I file a bug?
It definitely seems like a documentation bug to me.
I was passing zero for that parameter and (based on that line in the
docs) relying on the data array to be packed contiguously.
I have now changed my code to increment by 'bytesPerRow' as Andrew
suggested and all is well.
Thanks to Marc for bringing this to our attention, and to Andrew for
his quick and helpful response.
--
Cameron Hayne
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden