Hi cbporter,
I may be wrong, but It looks like you are trying to display every single update while you also want quick display.
Maybe you should disconnect display frequency from update frequency by appending all text adds in between two displays in one big text update (if this is possible with you're needs of corse)
I did something close to this when managing undo stack in my GraphCtrl : when doing quick zooming or panning (less than 300ms in between two actions), I append all actions in order to make one final undo action.
Hope this helps
edtPane.Insert(edtPane.Total(), str); // I added a test getter for total
edtPane.Insert(edtPane.Total(), str); edtPane.ScrollEnd();
edtPane.ScrollEnd()after insert prevents from drawing all text (added and present) : it probably only draws the last visible lines.
Yeah, using the code from Console that manipulates selection and uses Paste I got 11 seconds.
cbpporter wrote on Mon, 21 December 2015 12:39Yeah, using the code from Console that manipulates selection and uses Paste I got 11 seconds.
If you provide me with testcase, I can either advise what you are doing wrong, or, if nothing, optimize LineEdit
IMO there is not technical reason why that should be slow.
mirek wrote on Wed, 23 December 2015 18:03cbpporter wrote on Mon, 21 December 2015 12:39Yeah, using the code from Console that manipulates selection and uses Paste I got 11 seconds.
If you provide me with testcase, I can either advise what you are doing wrong, or, if nothing, optimize LineEdit
IMO there is not technical reason why that should be slow.
A test case is very simple. Try to compile in TheIDE code, which has a lot of errors/warnings, and TheIDE will frieze for several seconds. I do not know which part of TheIDE is responsible for that (parser, console, or new grid control with error messages), but profiling can help to figure that out. I spotted the problem when tried to compile one of my projects with a wrong compiler.
I was fixing that about year ago. Is it still an issue with current release? (Just want to be sure before I dive into it again...)
Anyway, the issue back then was not with LineEdit, but problem with pipe.
cbpporter wrote on Mon, 21 December 2015 12:39Yeah, using the code from Console that manipulates selection and uses Paste I got 11 seconds.
If you provide me with testcase, I can either advise what you are doing wrong, or, if nothing, optimize LineEdit
IMO there is not technical reason why that should be slow.
LineEdit le1; String s; loop { s << "Your values and text\n" ;} le1.Paste(s.ToWString()),
String s0,s1; Start with putting values to s0 When s0 is full start filling s1. Paste s0 to LineEdit. When s1 is full swith filling the s0. Paste s1 to LineEdit.
I posted profiling info here.
Thanks.
edtPane.Insert(edtPane.GetTotal(), str); edtPane.ScrollEnd();
Novo wrote on Sat, 09 January 2016 04:50I posted profiling info here.
Thanks.
I have checked it and if I understand it right, the issue has nothing to do with LineEdit. The problem there seems to be related to capturing errors for that nice new (since the last year) error window and with some checks invoked by ProcessEvents. I believe both could be fixed quite easily.
Mirek
mirek wrote on Tue, 12 January 2016 06:59Novo wrote on Sat, 09 January 2016 04:50I posted profiling info here.
Thanks.
I have checked it and if I understand it right, the issue has nothing to do with LineEdit. The problem there seems to be related to capturing errors for that nice new (since the last year) error window and with some checks invoked by ProcessEvents. I believe both could be fixed quite easily.
Mirek
Yes. It looks like the problem is not related to LineEdit directly. As I wrote previously " I do not know which part of TheIDE is responsible for that (parser, console, or new grid control with error messages)"
I cannot see anything related to the error window. It is all about Console which spends almost all time in Ide::FindLineError.