混合颜色空间有惩罚吗？ （核心显卡）
命令将活动填充颜色设置为红色：
CGContextSetRGBFillColor(context, 1.0, 0.0, 0.0, 1.0); // RGB(1,0,0)
如果我想要 50% 灰色，我可以调用：
CGContextSetRGBFillColor(context, 0.5, 0.5, 0.5, 1.0); // RGB(0.5,0.5,0.5)
如果我在 Mac OS X 或 iPhone OS 上的 Core Graphics 中编写绘图代码，我可以通过调用以下 灰色阴影很容易制作较短的行并调用：
CGContextSetGrayFillColor(context, 0.5, 1.0);
但是，此函数并不是简单地调用 RGB 方法并将强度值复制三遍；而是调用 RGB 方法。相反，它将上下文的颜色空间从 DeviceRGB 更改为 DeviceGray。下一次调用 RGB 方法会将其切换回来。
我很想知道：
- 切换色彩空间的惩罚是什么？
- 当上下文的颜色空间与设备的本机颜色空间不匹配时，绘图是否会受到惩罚？ （即，使用 DeviceGray 与 DeviceRGB 进行绘制）
我的提问是出于技术好奇心，而不是过早优化的愿望，所以请尽量减少您的警告。
If I'm writing drawing code in Core Graphics on Mac OS X or iPhone OS, I can set the active fill color to red by calling:
CGContextSetRGBFillColor(context, 1.0, 0.0, 0.0, 1.0); // RGB(1,0,0)
If I want 50% gray, I could call:
CGContextSetRGBFillColor(context, 0.5, 0.5, 0.5, 1.0); // RGB(0.5,0.5,0.5)
But for shades of gray it's tempting to make a shorter line and call:
CGContextSetGrayFillColor(context, 0.5, 1.0);
However, this function is NOT simply calling the RGB method with the intensity value copied three times; instead it is changing the context's color space from DeviceRGB to DeviceGray. The next call to an RGB method will switch it back.
I'm curious to know:
- What's the penalty for switching color spaces?
- Is there a penalty for drawing when your context's color space doesn't match your device's native color space? (i.e., drawing in DeviceGray versus DeviceRGB)
I'm asking out of technical curiosity, not a desire to prematurely optimize, so please keep your admonitions to a minimum, please.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从概念上讲，这是有惩罚的，但实际上它很小，以至于无关紧要；即使使用自定义颜色空间，将（例如）灰色阴影转换为 RGB 三元组（加上 alpha）也是微不足道的算术。
然而，当您绘制图像时，颜色空间确实会受到影响，因为它不仅仅是单个转换操作的问题。每个像素都必须进行转换，虽然可以在此处进行一些优化（例如 CLUT、颜色查找表，如果源图像使用索引颜色则非常有用），但它们在您还发现的情况下往往没有用。石英代码。
您说您期望 CGContextSetGrayFillColor() 更改图形上下文的颜色空间，但实际情况并非如此。这样做需要转换该图形上下文的内容以匹配上下文的新颜色空间。由于转换颜色而不是上下文缓冲区要便宜且简单得多（例如，通过将 CGContextSetGrayFillColor() 制作为 CGContextSetRGBFillColor() 的幕后包装器），这样在任何明智的实施中都可以避免费用。
Conceptually, there's a penalty, but in practice it's so miniscule as to be irrelevant; converting (e.g.) a shade of gray to an RGB triplet (plus alpha) is trivial arithmetic even with a custom colour space.
Colour spaces do have a penalty when you're drawing images, however, as it's more than a matter of a single conversion operation. Every pixel must be converted, and while there are optimizations that can be done here (e.g. CLUTs, Colour Look-Up Tables, are useful if the source image uses indexed colours) they don't tend to be useful in situations where you also find Quartz code.
You say you expect
CGContextSetGrayFillColor()to change the colour space of the graphics context, but that isn't actually the case. Doing so would necessitate converting the contents of that graphics context to match the context's new colour space. Since it's far cheaper and simpler to convert the colour instead of the context's buffers (e.g. by makingCGContextSetGrayFillColor()an under-the-covers wrapper aroundCGContextSetRGBFillColor()), such an expense is going to be avoided in any sensible implementation.我一直以类似的方式广泛使用两者，并且没有注意到性能方面的损失。
I have been using both extensively in a similar manner and have noticed no penalty in terms of performance.