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: Wed, 4 May 2005 12:00:55 -0400
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).
I am calling initWithBitmapDataPlanes with a zero value for
bytesPerRow. If I query the bytesPerRow and print it out, I see
that the bytesPerRow seems to be extended to a multiple of 32. It
doesn't seem to avoid powers of two.
Thanks - this is consistent with our experience. It was a painful
gotcha because most of the time, our images have numbers of rows that
*are* an even power of two so the non-32-alignment was never an
issue. It was only when we had images with - say 127 rows that the
problem arose. Note that I also never saw any indication that powers
of two were avoided. All our images that required an even power of
two row length (bytes or pixels) behaved as expected. What reason
could there be for avoiding powers of two?
--
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