慢速 WPF 文本框
我正在开发一个简单的串行数据查看器,它将用于观察传输到计算机串行端口之一的数据。我使用 C# 和 WPF 编写了一个测试应用程序;它只是将最近读取的行放入文本块中。但是,它会跳过所有其他行。我的理论是,在 WPF 渲染窗口之前,新数据会被放入文本块中。然而,我已经尝试了我能想到的所有线程优先级组合,并且应用程序最多显示每隔一行;最坏的情况是每 20 行显示一次。
我正在多核计算机上运行。我的应用程序由一个文本块和一个用于打开/关闭端口的按钮组成。 (我尝试用文本框替换文本块,并且发现了同样的问题)
我的 DataReceived 处理程序:
private void MainWindow_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
string message = sp.ReadLine();
if (string.IsNullOrWhiteSpace(message))
return;
this.Dispatcher.BeginInvoke(DispatcherPriority.Send, (ThreadStart)delegate()
{
text.Text = message;
this.InvalidateVisual();
});
}
此应用程序的最高优先级是处理大量数据的持续吞吐量; WPF 适合这种情况吗?如果是的话,我做错了什么?
I am developing a simple serial data viewer that will be used to watch the data being transmitted to one of a computer's serial ports. I wrote a test application using C# and WPF; it simply places the most recently read line into a textblock. However, it skips every-other line. My theory is that new data is being put into the textblock before WPF renders the window. However, I've tried every combination of thread priorities I can think of and, at best, the application shows every other line; at worst, it shows every 20 lines.
I am running on a multicore computer. My application consists of a textblock and a button to open/close the port. (I have tried replacing the textblock with a textbox, and I observe the same problem)
My DataReceived handler:
private void MainWindow_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
string message = sp.ReadLine();
if (string.IsNullOrWhiteSpace(message))
return;
this.Dispatcher.BeginInvoke(DispatcherPriority.Send, (ThreadStart)delegate()
{
text.Text = message;
this.InvalidateVisual();
});
}
The highest priority for this application is to handle sustained throughput of a lot of data; is WPF appropriate in this situation? If it is, what am I doing wrong?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我意识到这对游戏来说真的很晚了,但是在与这个问题斗争了大约一个月之后,我偶然发现了文本框更新缓慢的问题根源:
关闭文本换行完全消除了我的 UI 锁定问题:
TextWrapping =“NoWrap” “
当然,这意味着您需要更加负责地确保在通过 Environment.NewLine 更新文本框之前正确包装字符串,但在我看来,这是一个很小的代价。
希望这有帮助。
I realize this is really late to the game here, but after struggling with this issue for about a month now, I stumbled upon the source of my problems with slow textbox updating:
Turning off textwrapping completely removed my UI locking problem:
TextWrapping="NoWrap"
This, of course, will mean that you'll need to be more responsible for ensuring your strings are wrapped properly before updating the textbox via Environment.NewLine, but its a small price to pay in my opinion.
Hope this helps.
我公司的一款产品正在显示来自服务器的“近乎实时”的数据更新,您可以尝试以下几种操作....
您也许可以将文本移动到调度程序调用之外,如果您对其进行数据绑定而不是直接设置它。
您可以这样做:
添加依赖属性
在您的 xaml 文本框上
:其中 xNameOfMyWindow 是窗口标记的 x:Name 属性,
现在您的代码将如下所示:
One of my companies products is displaying "near real-time" updates of data from a server, and there are a couple of things you can try....
You might be able to move your text.Text outside of the dispatcher call if you databind it instead of directly setting it.
you can do this like so:
add a dependency property:
on your xaml textbox:
where xNameOfMyWindow is the x:Name attribute of your window tag
now your code would like this:
我有点晚了,但我遇到了这个问题。
我发现 SpellCheck 属性似乎会减慢 WPF 文本框中文本的输入速度。由于我需要拼写检查,我解决了这个问题,添加了一个简单的 Forms.Timer:当用户开始书写时,文本框的 textchanged 事件将禁用拼写检查并启动计时器。然后,当经过一秒时,计时器的滴答事件将启用拼写检查。
现在文本框的速度已经达到了应有的速度。
希望这可以帮助解决这个令人沮丧的问题的人。
I'm a bit late, but I ran in this problem.
What I've found it's that SpellCheck Property seems to slow down text entering in WPF Textboxes. Since I needed spell check, I worked around this issue adding a simple Forms.Timer: when the user starts writing, the textchanged event of the textbox disables spell check and starts the timer. Then, when one second is passed, the tick event of the timer enables spell check.
Now textboxes are fast as they should be.
Hope this can help someone with this frustrating issue.
我发现:使用 Courier 或 Consolas 等字体而不是 Segoe UI 可以使文本框更快。在我的测试用例中,35 秒降至 5 秒。
I found: using font type e.g. Courier or Consolas instead of Segoe UI makes the textbox much more faster. In my test case 35s dropped to 5s.