【问题标题】:WPF's RichTextBox performance issuesWPF 的 RichTextBox 性能问题
【发布时间】:2010-09-23 07:47:08
【问题描述】:

在处理任何实际数量的文本时,WPF 的 RTB 非常缓慢。实际数量,我的意思是你期望任何文本编辑器能够处理(100kb?至少)而不会显示任何缓慢的迹象。

这种预期的 RTB 行为对我来说并非如此。实际上,当文本被整齐地分成小词和小段落时,控件的工作原理非常相似,并且我实现了一些机制,只要他们勇敢地输入相当长的内容,就会让我的用户感到震惊。我还没有找到实现上述机制的方法,所以我不得不(或至少尝试)解决这个问题。

我觉得这非常令人不安,因为这对我来说没有任何意义。如果您是个胆大包天的人,并且碰巧输入了一长串没有空格或中断的字符,那么您会在几秒钟内成为锁定窗口的受害者,从而使输入成为不受欢迎的耐心考验。我急于知道的是:为什么会这样?具体来说,为什么它会越来越只有在文本间距不一致的情况下减慢速度?考虑到使用我的程序的人的空格键会损坏并因此更倾向于注意到这种令人难以置信的减速,我是否疯了?在这种连续字符串的情况下,文本选择也会受到严重影响。

我的目标是 .NET 4.0,使用 VS 2010,RTB 上没有任何事件;出于测试目的,它只是一个空窗口上的 RTB (< RichTextBox />)。我可以做些什么来提高它的性能?只为此编写我自己的控件,将功能设置为我的最低要求是否更现实?如果是这样,任何资源链接将不胜感激。

值得注意的是,RichTextBox 中的数据量可以非常少;我想澄清的是,真正对性能影响最大的是文本格式。

【问题讨论】:

  • 尚不清楚为什么有人愿意输入长时间不间断的字符串。

标签: .net wpf richtextbox


【解决方案1】:

对于文本框的新实现来说,这不是一个不寻常的问题。它与用于计算换行符的算法有关。根据您报告的行为类型,听起来他们使用的算法的效率在很大程度上取决于长度或单词(即,相对于单词的长度,它可能是 O(n^2) )。您应该直接向 Microsoft 报告此问题(提供一个明确的示例),以便他们修复错误。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-09-22
    • 1970-01-01
    • 2010-10-09
    相关资源
    最近更新 更多