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: Rick Hoge <email@hidden>
- Date: Tue, 3 May 2005 22:24:25 -0400
This is a change to the semantics of -initWithBitmapDataPlanes:...
It is now possible for the bitmap to not have packed bytesPerRow in
order to speed up drawing (something that was always possible, but
just didn't happen).
What is the preferred row width for fast drawing? We were able to
reverse engineer this solution and it looked like we had to provide
32 byte alignment (but we were pretty frantically trying to fix a
number of Tiger-related issues that cropped up so could be wrong. I
thought that 16 byte alignment was required to trigger AltiVec).
Rick
Your code assumes that the bitmap data is packed and so as you fill
up the bitmap, you start getting skewed rows. Either pass in an
explicit bytesPerRow value instead of zero to -
initWithBitmapDataPlanes:... to explicitly indicate packed values
or change your loop to be something like:
unsigned char* row = destbuffer;
int i, j;
for (i = 0; i < height; i++, row += [imageRep bytesPerRow]) {
unsigned char* p = row;
for (j = 0; j < width; j++) {
*p++ = c;
*p++ = c;
*p++ = c;
c++;
}
}
Note that in Panther compiled apps, we should still alloc packed
bytesPerRow for compatibility. I assume you recompiled on Tiger.
Andrew Platzer
Application Frameworks
Apple Computer, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40nmr.mgh.harvard.edu
This email sent to 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