我注意到一些有点恼人的东西.
RichTextBox的性能是非常糟糕的,每当UI被调整大小,并且RichTextBox有很多文本导致其包装算法触发.
这给应用程序一个非常马虎的感觉,好像它的优化很差(即使不是).
起初我注意到这个性能在选择文本时打了,所以不用使用SelectionChanged事件,我决定使用PrevIEwMouseUp事件,然后获取Selection.
然后经过进一步测试,我发现调整大小也造成了巨大的负担.
而我正在谈论的负载在5% – > 30%的四核cpu运行在3.8GHz!
为了进一步测试,我决定评论我的RichTextBox,只包括一个新的RichTextBox没有定义的属性
<RichTextBox/>
将其插入窗口,填充文本,然后重新调整窗口大小,使包装算法再次执行相同 *** 作,最多可使用30%!
我试图研究这个问题,大多数人最终建议将PageWIDth设置为高值,以防止包装:
richTextBox1.HorizontalScrollbarVisibility = ScrollbarVisibility.Visible;richTextBox1.document.PageWIDth = 1000;
我不想要的,因为我以前写的编辑器版本是使用WinForms进行的,可以毫不费力地进行包装,我也希望在新的WPF版本中.
有没有人面对这个问题?
如果是的话,请指点我正确的方向去除硬件上的巨大压力?
我有点伤心,因为我喜欢WPF,但是我确实发现一个或另一个对象真的没有优化和/或不实用,与WinForms对手相比,RichTextBox似乎是另外一个例子:
对不起,大量的文本,但我真的想要这样整齐地记录,以防一些其他可怜的灵魂面对这个问题,你们看到我迄今为止所尝试的.
解决方法 克服此问题的一种方法可能是在窗口大小调整时切换到“无包装”模式,但是当用户完成调整大小时 – 切换回正常模式.然后,包装算法最终将执行一次,用户应该仍然对您的应用程序感到光滑.示例代码:public partial class MainWindow : Window{ public MainWindow() { InitializeComponent(); this.SizeChanged += OnSizeChanged; } private Timer _timer; private voID OnSizeChanged(object sender,SizeChangedEventArgs e) { // user started resizing - set large page wIDth textBox.document.PageWIDth = 1000; // if we already setup timer - stop it and start all over if (_timer != null) { _timer.dispose(); _timer = null; } _timer = new Timer(_ => { // this code will run 100ms after user _stopped_ resizing dispatcher.Invoke(() => { // reset page wIDth back to allow wrapPing algorithm to execute textBox.document.PageWIDth = double.NaN; }); },null,100,Timeout.Infinite); }}总结
以上是内存溢出为你收集整理的c# – RichTextBox – UI调整大小导致巨大的CPU负载全部内容,希望文章能够帮你解决c# – RichTextBox – UI调整大小导致巨大的CPU负载所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)