简体   繁体   English

绘制大型CGPath的最有效方法是什么?

[英]What's the most efficient way to draw a large CGPath?

Alright, I have a UIView which displays a CGPath which is rather wide. 好吧,我有一个UIView ,它显示了一个相当宽的CGPath It can be scrolled within a UIScrollView horizontally. 可以在UIScrollView水平滚动它。 Right now, I have the view using a CATiledLayer , because it's more than 1024 pixels wide. 现在,我有一个使用CATiledLayer的视图,因为它的宽度超过1024像素。

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? 有人知道这是否是个坏主意,还是CGContext仅在绘制裁剪矩形内的路径部分相对聪明?

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? 朝这个方向发展是否值得,还是CGPath已经相对迅速地绘制了?

By necessity Quartz must clip everything it draws against the dimensions of the CGContext it's drawing into. 根据需要,Quartz必须将其绘制的所有内容都与要绘制的CGContext的尺寸相对应。 But it will still save CPU if you only send it geometry that is visible within that tile. 但是,如果仅向其发送在该图块中可见的几何图形,它将仍然节省CPU。 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. 如果您通过准备多个路径(每个图块一个)来进行此操作,则意味着要进行一次剪辑(在创建多个路径时),而Quartz每次绘制图块时都要进行剪辑。 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. 您可以做的是使用仪器来观察Quartz花费了多少时间,然后再疯狂优化材料。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM