WPF的RichTextBox性能问题
在处理任何实际数量的文本时，WPF 的 RTB 都非常慢。就实际数量而言，我的意思是您期望任何文本编辑器能够处理（100kb？至少）而不会表现出任何缓慢迹象。
这种预期的 RTB 行为对我来说并非如此。实际上，当文本被整齐地分成小单词和小段落时，该控件的工作原理非常相似，并且我实现了一些机制，每当用户勇敢地输入相当长的内容时，就会使他们感到震惊。我还没有找到实现上述机制的方法，所以我被迫（或至少尝试）解决这个问题。
我觉得这非常令人不安，因为这对我来说没有任何意义。如果您是一个胆大妄为的人，碰巧输入了一长串没有空格或中断的字符，那么您将在几秒钟内成为锁定窗口的受害者，这使得打字成为对耐心的不受欢迎的考验。我急于想知道的是：这是为什么？具体来说，为什么当文本间距不一致时，它会越来越并且仅变慢？考虑到使用我的程序的人的空格键会损坏，从而更容易注意到这种令人难以置信的减速，我是否疯了？在这种连续字符串的情况下，文本选择也会受到严重影响。
我的目标是 .NET 4.0，使用 VS 2010，RTB 上没有挂钩任何事件；出于测试目的，它只不过是空窗口上的 RTB (
值得注意的是，RichTextBox 中的数据量可能非常小；我想澄清的是，文本的格式确实对性能影响最大。
WPF's RTB is terribly slow when working with any realistic amount of text. And by realistic amount, I mean what you'd expect any text editor to be able to handle (100kb? At least) without showing any signs of slowness.
This expected RTB behavior is not the case for me. Actually, the control works pretty much like it should when text is neatly separated into small words and small paragraphs and I implement some mechanism that will zap my users' whenever they get brave and type anything considerably long. I haven't found a way to implement said mechanism yet, so instead I'm forced to (or at least attempt to) solve the problem.
I find this deeply disturbing because it makes no real sense to me. If you're a daredevil and happen to type out one long string of characters without a space or break, you fall victim to a locked window for several seconds, making typing an unwelcome test of patience. What I'm anxious to know is: why is that? Specifically, why does it slow down more and more and only when text isn't spaced consistently? Am I insane to consider the case that someone using my program will have a broken space bar and will thus be more inclined to notice this incredible slowdown? Text selection is also gravely affected in this contiguous-string case.
I'm targeting .NET 4.0, using VS 2010, and no events are hooked on the RTB; for testing purposes it's nothing but a RTB (< RichTextBox />) on an empty window. What can I do to improve its performance? Is it more realistic to just write my own control for this, keeping the feature set to my minimum requirements? If so, any links to resources would be greatly appreciated.
It's worth noting that the amount of data in the RichTextBox can be really small; what I was trying to make clear was that it's the format of the text that really had the biggest impact on performance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于文本框的新实现来说，这并不是一个不寻常的问题。它与用于计算换行符的算法有关。根据您报告的行为类型，听起来他们使用的算法的效率很大程度上取决于单词的长度（即，相对于单词的长度，它可能是 O(n^2) ）。您应该直接向 Microsoft 报告此问题（并提供清晰的示例），以便他们可以修复该错误。
This is not an unusual problem for new implementations of text boxes. It has to do with the algorithm used for calculating line breaks. Based on the kind of behaviour you're reporting, it sounds like the efficiency of the algorithm they use is strongly dependent on the length or words (i.e. it might be, say, O(n^2) with respect to the length of words). You should report this directly to Microsoft (with a clear example) so that they can fix the bug.