WPF PathGeometry/RotateTransform 优化
我在渲染/旋转 WPF 三角形时遇到性能问题
如果我显示了一个 WPF 三角形，并且它将围绕中心点旋转到一定程度，我可以通过以下两种方式之一执行此操作：
以编程方式确定点及其偏移量在后端，使用 XAML 将它们简单地放置在它们所属的画布上，它看起来像这样：
<路径描边=“黑色”> <路径.数据> <路径几何>每次生成“相同”三角形，然后使用 RenderTransform（旋转）将其放置在其所属的位置。 在这种情况下，旋转计算被混淆了，因为我无权了解它们是如何完成的。
<路径描边=“黑色”> <路径.数据> <路径几何><路径.RenderTransform>
我的问题是哪一个更快？
我知道我应该自己测试它，但是如何测量具有如此粒度的对象的渲染时间。 我需要能够计算出表单的实际渲染时间有多长，但由于我不是启动重绘的人，所以我不知道如何捕获开始时间。
I am having performance issues when rendering/rotating WPF triangles
If I had a WPF triangle being displayed and it will be rotated to some degree around a centrepoint, I can do it one of two ways:
Programatically determine the points and their offset in the backend, use XAML to simply place them on the canvas where they belong, it would look like this:
<Path Stroke="Black"> <Path.Data> <PathGeometry> <PathFigure StartPoint ="{Binding CalculatedPointA, Mode=OneWay}"> <LineSegment Point="{Binding CalculatedPointB, Mode=OneWay}" /> <LineSegment Point="{Binding CalculatedPointC, Mode=OneWay}" /> <LineSegment Point="{Binding CalculatedPointA, Mode=OneWay}" /> </PathFigure> </PathGeometry> </Path.Data> </Path>Generate the 'same' triangle every time, and then use a RenderTransform (Rotate) to put it where it belongs. In this case, the rotation calculations are being obfuscated, because I don't have any access to how they are being done.
<Path Stroke="Black"> <Path.Data> <PathGeometry> <PathFigure StartPoint ="{Binding TriPointA, Mode=OneWay}"> <LineSegment Point="{Binding TriPointB, Mode=OneWay}" /> <LineSegment Point="{Binding TriPointC, Mode=OneWay}" /> <LineSegment Point="{Binding TriPointA, Mode=OneWay}" /> </PathFigure> </PathGeometry> </Path.Data> <Path.RenderTransform> <RotateTransform CenterX="{Binding Centre.X, Mode=OneWay}" CenterY="{Binding Centre.Y, Mode=OneWay}" Angle="{Binding Orientation, Mode=OneWay}" /> </Path.RenderTransform> </Path>
My question is which one is faster?
I know I should test it myself but how do I measure the render time of objects with such granularity. I would need to be able to time how long the actual rendering time is for the form, but since I'm not the one that's kicking off the redraw, I don't know how to capture the start time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否尝试过使用 WPF 性能工具<中包含的 Perforator 或 Visual Profiler< /a>? 从文档来看，这些工具应该能够为您提供所需的信息。 您必须以第一种方式构建应用程序，使用这些工具对其进行测试，记下性能信息，然后与以第二种方式构建的应用程序重新进行比较。
Have you tried using either the Perforator or the Visual Profiler included in the WPF performance tools? From the documentation it looks like these tools should be able to get you the information you're looking for. You'd have to build your application the first way, test it with these tools, take note of the performance information, and then do it all over again with the application built the second way to compare.
您可以像这样覆盖表单的 OnPaint 方法（伪代码）：
还是我太天真了？
You could override the form's OnPaint method like this (pseudo code):
or am I being incredibly naive?