在这个CGBitmapContextCreate中，为什么bytesPerRow为0？ [英] In this CGBitmapContextCreate, why is bytesPerRow 0?

问题描述

我注意到在Apple的示例代码中，它们通常在CGBitmapContextCreate的bytesPerRow参数中提供值0。例如，这来自反射示例项目。

I've noticed in Apple's sample code that they often provide a value of 0 in the bytesPerRow parameter of CGBitmapContextCreate. For example, this comes out of the Reflection sample project.

CGContextRef gradientBitmapContext = CGBitmapContextCreate(NULL, pixelsWide, pixelsHigh,  
                                                            8, 0, colorSpace, kCGImageAlphaNone);

这对我来说似乎很奇怪，因为我总是走的是将图像宽度乘以的路线每个像素的字节数。我尝试将零交换到我自己的代码中并进行测试。果然，它仍然有效。

That seemed odd to me, since I've always gone the route of multiplying the image width by the number of bytes per pixel. I tried swapping in a zero into my own code and tested it out. Sure enough, it still works.

size_t bitsPerComponent = 8;
size_t bytesPerPixel = 4;
size_t bytesPerRow = reflectionWidth * bytesPerPixel;   

CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef context = CGBitmapContextCreate(NULL,
                                             reflectionWidth,
                                             reflectionHeight,
                                             bitsPerComponent,
                                             0, // bytesPerRow ??
                                             colorSpace,
                                             kCGImageAlphaPremultipliedLast);

根据文档，bytesPerRow应为每行使用的内存字节数位图。

According to the docs, bytesPerRow should be "The number of bytes of memory to use per row of the bitmap."

那么这笔交易是什么？我何时可以提供零，何时必须计算确切的值？以某种方式做到这一点有什么性能影响吗？

So whats the deal? When can I supply a zero and when must I calculate the exact value? Are there any performance implications of doing it one way or the other?

推荐答案

我的理解是，如果你传入零，它根据bitsPerComponent和width参数计算每行的字节数。您可能希望在每行字节的末尾添加额外的填充（如果您的设备需要它，或者其他一些约束）。在这种情况下，您可以传递一个不仅仅是宽度*（每个像素的字节数）的值。我想在现代i / MacOS开发中可能永远不需要这样做，除了一些奇怪的边缘情况优化。

My understanding is that if you pass in zero, it calculates the bytes-per-row based on the bitsPerComponent and width arguments. You might want additional padding at the end of each row of bytes (if your device required it, or some other constraint). In this case, you could pass a value that was more than just width * (bytes per pixel). I would imagine this is probably never needed in modern i/MacOS development, except for some weird edge-case optimizations.

这篇关于在这个CGBitmapContextCreate中，为什么bytesPerRow为0？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！