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: Shawn Erickson <email@hidden>
- Date: Tue, 3 May 2005 19:32:14 -0700
On May 3, 2005, at 7:24 PM, Rick Hoge wrote:
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).
This is the logic I use which I believe was lifted from some vImage
documentation. I would assume it would be similar for this.
void InitImageBuffer( vImage_Buffer* buffer, int height, int width,
size_t bytesPerPixel ) {
size_t rowBytes = width * bytesPerPixel;
//Widen rowBytes out to a integer multiple of 16 bytes
rowBytes = (rowBytes + 15) & ~15;
//Make sure we are not an even power of 2 wide.
//Will loop a few times for rowBytes <= 16.
while( 0 == (rowBytes & (rowBytes - 1) ) )
rowBytes += 16; //grow rowBytes
//Set up the buffer
buffer->height = height;
buffer->width = width;
buffer->rowBytes = rowBytes;
buffer->data = malloc( rowBytes * height );
}
Yeah here and it explains the reasoning...
<http://developer.apple.com/documentation/Performance/Conceptual/
vImage/Chapter3/chapter_3_section_6.html>
As a side note I just noticed that vImage supports ppc64 on Tiger :-)
-Shawn
_______________________________________________
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