When scaning the second line, it begins form bandBuffer + bandWidth * 4. And the second line data is kPMXRGB_32 format data.
The kPMRGB_24 format data is more fast than kPMXRGB_32 format data when dealing or translating them???
Re:
On Oct 14, 2005, at 11:41 AM, email@hidden wrote:
>
> These comments refer to Tioga drivers, which is what
> you appear to be making:
>
> 1. Because I had a lot of problems in the earlier OS versions
> with various formats, I stick with kPMXRBGB_32 and just
> throw away the bytes I don't need.
>
> 2. The PMJobStreamGetNextBand routine returns with a structure
> describing the band. The structure doesn't have a width, but
> widthInBytes = band.size / band.height
> and
> widthInPixels = widthInBytes * 8 / band.depth,
>
> so the second line begins widthInBytes past the first line.
This strategy for computing the width of a scanline from the
band.size field
will definitely fail for the kPMRGB_24 case for the reasons I mentioned
in my earlier message.!
It may
work well for some formats but definitely
not for that one at this point in time.
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Printing mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/printing/email@hidden
This email sent to email@hidden
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
雅虎助手－搜索、杀毒、防骚扰
