gdb output window performance

[Jens Dagerbo]

On Wednesday 12 April 2006 15:16, Vladimir Prus wrote:
> On Wednesday 12 April 2006 19:04, Andras Mantia wrote:
> > On Wednesday 12 April 2006 17:54, Vladimir Prus wrote:
> > > The call to 'scrollToBottom' was commented just now, and has no
> > > apparanent effect on performance. The 'm_gdbView' is QTextEdit.
> > > Before I go and write my own GdbLogginWidgetImplementedAsQScrollArea,
> > > maybe somebody knows any possible reason why QTextEdit is that slow?
> >
> > Well, I'm sure QTextEdit was not designed for this purpose ("QTextEdit
> > is an advanced WYSIWYG viewer/editor supporting rich text formatting
> > using HTML-style tags..."), unless you use in LogText mode. If you are
> > already using that mode, I see no other solution, but make a faster
> > logging widget.
>
> Per Jens' suggestion, I've tried using:
>
>     setTextFormat(LogText);
>
> which has no noticable effect whatsoever. Maybe I can try disabling updates
> for the widget, so that it does not repait itself on each gdb command, but
> if that fails, I'll put together a small logging widget using QScrollArea.
> Should not be very hard ;-)
>

I was literary putting on my jacket as I wrote the above suggestion, so I had 
no time to expand on alternatives.. ;)

I've been doing some work trying to optimize the output of a realtime logging 
application based on the Windows RichText Control at work. It's also a pig 
and can be really slow if used incorrectly.

The best solution I found is exactly what Alexander Neundorf suggested 
elsewhere in this thread - buffer the data and push it into the QTextEdit on 
fewer occasions. If it's anything like the Windows control, it's not the 
painting that's slow, it's the append operation. The only solution is to do 
less of them (with more data). Give it a try before making your own 
widget. :)

// jens