WPF TextBlock 性能如此缓慢是预期的吗?
我正在做一些基准测试以确定是否可以将 WPF 用于新产品。然而,早期的表现结果令人失望。我制作了一个快速应用程序,它使用数据绑定每 100 毫秒在列表框中显示一堆随机文本,它占用了约 15% 的 CPU。因此,我制作了另一个快速应用程序,它跳过了数据绑定/数据模板方案,除了每 100 毫秒更新一次列表框内的 10 个 TextBlock 之外什么也不做(实际产品不需要 100 毫秒更新,更像是最多 500 毫秒,但是这是一个压力测试)。我仍然看到约 5-10% 的 CPU 使用率。为什么这么高?是因为所有的垃圾字符串吗?
以下是不使用绑定的版本的 XAML:
<Grid>
<ListBox x:Name="numericsListBox">
<ListBox.Resources>
<Style TargetType="TextBlock">
<Setter Property="FontSize" Value="48"/>
<Setter Property="Width" Value="300"/>
</Style>
</ListBox.Resources>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
</ListBox>
</Grid>
这是背后的代码:
public partial class Window1 : Window
{
private int _count = 0;
public Window1()
{
InitializeComponent();
}
private void OnLoad(object sender, RoutedEventArgs e)
{
var t = new DispatcherTimer(TimeSpan.FromSeconds(0.1), DispatcherPriority.Normal, UpdateNumerics, Dispatcher);
t.Start();
}
private void UpdateNumerics(object sender, EventArgs e)
{
++_count;
foreach (object textBlock in numericsListBox.Items)
{
var t = textBlock as TextBlock;
if (t != null)
t.Text = _count.ToString();
}
}
}
根据任务管理器,它消耗约 5-10% 的 CPU,或者高达其中一个核心的 20% 左右!对于快速渲染文本的更好方法有什么想法吗?
我的电脑:XP SP3、2.26 GHz Core 2 Duo、4 GB RAM、Intel 4500 HD 集成显卡。这比我在实际产品中需要开发的硬件要强大一个数量级。
I am doing some benchmarking to determine if I can use WPF for a new product. However, early performance results are disappointing. I made a quick app that uses data binding to display a bunch of random text inside of a list box every 100 ms and it was eating up ~15% CPU. So I made another quick app that skipped the data binding/data template scheme and does nothing but update 10 TextBlocks that are inside of a ListBox every 100 ms (the actual product wouldn't require 100 ms updates, more like 500 ms max, but this is a stress test). I'm still seeing ~5-10% CPU usage. Why is this so high? Is it because of all the garbage strings?
Here's the XAML for the version that doesn't use binding:
<Grid>
<ListBox x:Name="numericsListBox">
<ListBox.Resources>
<Style TargetType="TextBlock">
<Setter Property="FontSize" Value="48"/>
<Setter Property="Width" Value="300"/>
</Style>
</ListBox.Resources>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
<TextBlock/>
</ListBox>
</Grid>
Here's the code behind:
public partial class Window1 : Window
{
private int _count = 0;
public Window1()
{
InitializeComponent();
}
private void OnLoad(object sender, RoutedEventArgs e)
{
var t = new DispatcherTimer(TimeSpan.FromSeconds(0.1), DispatcherPriority.Normal, UpdateNumerics, Dispatcher);
t.Start();
}
private void UpdateNumerics(object sender, EventArgs e)
{
++_count;
foreach (object textBlock in numericsListBox.Items)
{
var t = textBlock as TextBlock;
if (t != null)
t.Text = _count.ToString();
}
}
}
That consumes ~5-10% CPU according to Task Manager, or up to about 20% of one of the cores! Any ideas for a better way to quickly render text?
My computer: XP SP3, 2.26 GHz Core 2 Duo, 4 GB RAM, Intel 4500 HD integrated graphics. And that is an order of magnitude beefier than the hardware I'd need to develop for in the real product.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这种缓慢的 TextBlock 性能正常吗?
不。这种缓慢的 TextBlock 性能绝对不正常。我的经验是 TextBlock 比这快得多。
我使用您发布的代码运行了几次测试,将更新间隔保留为 0.1 秒,并改变硬件和 TextBlock 的数量。以下是我的发现:
这些测试中的每一项都表明 WPF 的速度大约是您的测量值的 10 倍。如果您的代码像看起来一样简单,我怀疑您的 GPU 或 DirectX 驱动程序出现了奇怪的情况。
请注意,对于 100 个 TextBlock 测试,我必须进行三项更改:添加 90 个 TextBlock、将 ItemsPanel 设置为 WrapPanel 以获取列中的数据,以及减小 TextBlock 宽度以使所有内容适合屏幕。
我在 200MHz Pentium Pro 上进行的测试可能与您的嵌入式硬件最相关。如果您的应用程序每 0.5 秒更新 10 个 TextBlock,您预计将使用大约 3% 的 CPU 来在 200MHz CPU 上进行更新和重绘。
如果我想让速度更快怎么办?
使用数据绑定 TextBlock 列表非常方便,但 WPF 还提供了较低级别的机制,可以在需要绝对最大性能时使用。
WPF TextBlock 实际上包含格式化文档而不仅仅是字符串,因此它是一个非常复杂的数据结构。编写自己的
TrivialTextBlock
控件非常简单,该控件具有一个字符串参数,并使用继承的 TextElement 属性(例如 FontSize、FontWeight 等)简单地绘制它。通常不会这样做,因为 TextBlock 的速度足以满足几乎所有用途。另一个考虑因素是,每次更改 TextBlock 中的文本时,WPF 都会重新计算布局。与旧技术不同,WPF TextBlock 的内容可以非常轻松地更改 UI 的布局。因此,每次更改文本时都必须重新测量和重新格式化。创建上述的 TrivialTextBlock 控件也可以通过固定控件大小来加快速度,从而避免布局传递。
第三个考虑因素是 WPF 的文本格式化程序具有高级排版功能,支持字距调整、双向文本、连字、unicode 功能、自定义字体粗细等。要在 WPF 中获得绝对最大性能,您可以完全绕过文本格式化程序并绘制您的文本。文本作为一系列图像。这需要大约 20 行 XAML 和大约 40 行 C# 代码。
所有这些优化都是可能的,但在你的情况下,我不会打扰它们:这样做只是为了节省 3% 的 CPU 使用率可能不值得。
Is this slow TextBlock performance normal?
No. Such slow TextBlock performance is definitely not normal. My experience has been TextBlocks are much faster than that.
I ran several tests using the code you posted, leaving the update interval at 0.1s and varying the hardware and number of TextBlocks. Here is what I found:
Every one of these tests suggests that WPF is approximately 10x as fast as your measurements indicate. If your code is as simple as it appears, my suspicion would be that there is something strange going in with your GPU or DirectX drivers.
Note that for the 100 TextBlock tests I had to make three changes: Adding 90 TextBlocks, setting the ItemsPanel to a WrapPanel to get the data in columns, and reducing the TextBlock width to get everything to fit on screen.
My test on the 200MHz Pentium Pro is probably the most relevant to your embedded hardware. If your application updates 10 TextBlocks every 0.5s you can expect to use approximately 3% of the CPU for the update and redraw on a 200MHz CPU.
What if I want to make it even faster?
Using a list of data-bound TextBlocks is very convenient but WPF also provides lower-level mechanisms that can be used when you need absolute maximum performance.
A WPF TextBlock actually contains a formatted document not just a string, so it is a very complex data structure. It is quite simple to write your own
TrivialTextBlock
control which has a string parameter and simply draws it using the inherited TextElement properties (such as FontSize, FontWeight, etc). This is usually not done because TextBlock is fast enough for almost all purposes.Another consideration is that every time you change the text in a TextBlock, WPF recomputes the layout. Unlike older technologies, the content of a WPF TextBlock can very easily change the layout of your UI. So the text must be remeasured and reformatted every time you change it. Creating the aforementioned
TrivialTextBlock
control can speed this up as well by fixing the control size and thereby avoiding layout passes.A third consideration is that WPF's text formatter has advanced typography features, supporting such things as kerning, bidirectional text, ligatures, unicode features, custom font weights, etc. To get absolute maximum performance in WPF you can bypass the text formatter entirely and draw your text as a series of images. This requires about 20 lines of XAML and about 40 lines of C# code.
All of these optimizations are possible, but in your case I wouldn't bother with them: Doing it to save a mere 3% CPU usage is probably not worth it.
就性能而言,WPF 中可能存在很多错误。很多人将其视为 win 表单应用程序、html 网页或开发应用程序时的某种混合攻击,因此对 WPF 有很多不好的评价。
据我了解,您正在尝试进行性能测试,以查看 WPF 是否适用于您的平台,并且可以在以下链接中找到有关如何让 WPF 应用程序控件执行您期望的负载类型的一个很好的示例。
http://msdn.microsoft.com/en-us/magazine/dd483292。 aspx
Petzold 指导您完成优化项目控件的过程,以最佳地呈现 UI 上显示的数据负载。
为了进行公平的测试,我将编写一个示例应用程序来处理您将要处理的数据样本,然后测试该代码的性能。有大量的优化可用于使 WPF 应用程序运行良好并使用更少的 CPU,但它们都取决于您的应用程序及其表示数据的方式。
希望这有帮助。
There is a lot one can do wrong in WPF, as far as performance is concerned. Lot of people approach it like a win forms application, html web page, or some hybrid attack on developing the application and because of this there are a lot of bad evaluations of WPF.
I understand that you are trying to do performance testing to see if a WPF can work for your platform and a good example of how to get your WPF application control to perform for the type of load you are expecting can be found at the below link.
http://msdn.microsoft.com/en-us/magazine/dd483292.aspx
Petzold guides you through the process of optimizing an items control to render optimally for the load of data being displayed on the UI.
To do a fair test I would write a sample application that deals with a sample of the data you are going to be dealing with, and then test the performance of that code. There are a large number of optimizations that can be applied to make a WPF application scream and use less CPU, but they all depend on your application and how it is representing your data.
Hope this helps.
如果您确定您的部署硬件非常好,我只会将 WPF 用于新产品。实际上,我认为独立显卡是最低要求。
我的团队为针对 Atom 处理器平台的项目选择了 WPF,因为集成的 GMA 500 显卡要求 WPF 渲染第 2 层。但是,由于某种原因,GMA 500 的性能非常慢,我们关闭了硬件渲染以获得更好的性能。即便如此,Atom 平台的性能仍不足以实现合理的性能。如果上网本或任何采用 Intel Atom 的产品是您的客户群的一部分,我建议不要使用 WPF。
这是我在WPF 在 GMA 500 上的性能。
正如 Rob Perkins 所建议的,您可能最好使用 Silverlight 4 以获得更好的性能。
祝你好运!
I would only use WPF for a new product if you are certain your deployment hardware is quite good. Practically speaking, I think a dedicated graphics card is a minimum requirement.
My team selected WPF for a project targeted at an Atom processor platform because the integrated GMA 500 graphics claimed WPF render Tier 2. However, for some reason the performance of the GMA 500 is very slow and we turned hardware rendering off to get better performance. Even then, the Atom platform is underpowered for reasonable performance. I advise not using WPF if netbooks or anything with Intel Atom is part of your customer base.
Here is a link to a question I have open on the performance of WPF on GMA 500.
As Rob Perkins suggests, you may be better off with Silverlight 4 for better performance.
Good luck!