绘制大型 CGPath 最有效的方法是什么？
好吧，我有一个 UIView，它显示一个相当宽的 CGPath。 它可以在 UIScrollView 内水平滚动。 现在，我使用 CATiledLayer 来查看视图，因为它的宽度超过 1024 像素。
所以我的问题是：这有效吗？
- (void) drawRect:(CGRect)rect {
CGContextRef g = UIGraphicsGetCurrentContext();
CGContextAddPath(g,path);
CGContextSetStrokeColor(g,color);
CGContextDrawPath(g,kCGPathStroke);
}
本质上，每次绘制图层中的图块时，我都会绘制整个路径。 有谁知道这是否是一个坏主意，或者 CGContext 相对聪明地只绘制剪切矩形内的路径部分？
路径主要是以这样的方式设置的，我可以将其分成大小和形状与图块相似的块，但这需要我做更多的工作，需要路径之间有一些冗余（对于跨越图块边界），并且还需要一些计算来找到要绘制的一条或多条路径。
朝这个方向移动是否值得，或者 CGPath 已经绘制得相对较快了？
Alright, I have a UIView which displays a CGPath which is rather wide. It can be scrolled within a UIScrollView horizontally. Right now, I have the view using a CATiledLayer, because it's more than 1024 pixels wide.
So my question is: is this efficient?
- (void) drawRect:(CGRect)rect {
CGContextRef g = UIGraphicsGetCurrentContext();
CGContextAddPath(g,path);
CGContextSetStrokeColor(g,color);
CGContextDrawPath(g,kCGPathStroke);
}
Essentially, I'm drawing the whole path every time a tile in the layer is drawn. Does anybody know if this is a bad idea, or is CGContext relatively smart about only drawing the parts of the path that are within the clipping rect?
The path is mostly set up in such a way that I could break it up into blocks that are similar in size and shape to the tiles, but it would require more work on my part, would require some redundancy amongst the paths (for shapes that cross tile boundaries), and would also take some calculating to find which path or paths to draw.
Is it worth it to move in this direction, or is CGPath already drawing relatively quickly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Quartz 必须根据它所绘制的 CGContext 的尺寸来裁剪它所绘制的所有内容。 但如果您只发送该图块中可见的几何图形，它仍然会节省 CPU。 如果您通过准备多个路径（每个图块一个）来做到这一点，那么您所说的是一次剪辑（当您创建多个路径时），而不是 Quartz 每次绘制图块时都会进行一次剪辑。 效率增益将取决于您的路径的复杂程度：如果是一些简单的形状，没什么大不了的；如果是，则没什么大不了的。 如果它是国家公路网的矢量绘制地图，它可能会很大！ 当然，您必须以这种加速与代码复杂性的增加进行权衡。
在你疯狂优化之前，你可以做的是使用工具来查看在 Quartz 上花费了多少时间。
By necessity Quartz must clip everything it draws against the dimensions of the CGContext it's drawing into. But it will still save CPU if you only send it geometry that is visible within that tile. If you do this by preparing multiple paths, one per tile, you're talking about doing that clipping once (when you create your multiple paths) versus Quartz doing it every time you draw a tile. The efficiency gain will come down to how complex your path is: if it's a few simple shapes, no big deal; if it's a vector drawn map of the national road network, it could be huge! Of course you have to trade this speedup off against the increased complexity of your code.
What you could do is use instruments to see how much time is being spent in Quartz before you go crazy optimizing stuff.