[QT 4] QTextEdit performance

[fellobo]

:eek: I tell ya what I am not that impressed with the QTextEdit performance. I have a thread running some code and all it does is send a msg to my GUI (append to QTextEdit) and it doesn't update at all until after my thread is completed.

I've read that other people have said the performance is bad but was told to use a QTable.

Why use a QTable when QTextEdit is really what I want? hmm... :confused:

Is there a way to improve the speed of updating. I have a QProgressbar and it gets a call at the same time I send a call to the QTextEdit (while the progressbar updates great the textedit does not.)

Anythoughts?

[GreyGeek]

:eek: I tell ya what I am not that impressed with the QTextEdit performance. I have a thread running some code and all it does is send a msg to my GUI (append to QTextEdit) and it doesn't update at all until after my thread is completed.

I've read that other people have said the performance is bad but was told to use a QTable.

Why use a QTable when QTextEdit is really what I want? hmm... :confused:

Is there a way to improve the speed of updating. I have a QProgressbar and it gets a call at the same time I send a call to the QTextEdit (while the progressbar updates great the textedit does not.)

Anythoughts?

Seems to work fast enough for me. The "qQpp->processEvents();" call updates the QTextEdit control as fast as the Windows events que will allow.


ui.leStatus->setText("Preparing XTab Report...");
this->setCursor(Qt::WaitCursor);
qApp->processEvents();

[fellobo]

hmmm, I am using the QTextEdit::append(QString); I wonder if that is why.....

it would look like this:



for(int x = 0; x < 1000; x++)
{
my_qtext_edit_ptr->append(tr("this is another line %1").arg(x));

QTextCursor cursor(my_qtext_edit_ptr->textCursor());
cursor.movePosition(QTextCursor::End, QTextCursor::MoveAnchor);
my_qtext_edit_ptr->setTextCursor(cursor);

// although I've had this in there it didn't seem to help much
QApplication::processEvents();


}




I will go and try this exact thin and post my results....
And thanks for replying to my post.

[fellobo]

Good test, I set it up and it ran like I expected it to (fast and good.) But then I started to change things. What I have is a thread, right, so the way my thread sends the message back is threw and signal and a slot.

I placed within my thread the for loop and had it send back the message back via emit and it gave the display. So, would it be in the emit or would it be within the thread?

My thread is very simple thread.


// with in the basic run I have
for(int x = 0; x < 1000; x++)
{
send(tr("I want more lines\nthis is another line %1").arg(x));
}

// where send is a function

void my_thread::send(QString msg)
{
emit send_msg(msg);
}


now my connect on my gui looks like this



connect(mp_thread, SIGNAL(send_msg(QString)), this,
SLOT(append_output(QString)));

// and my funciton

void my_gui::append_output(QString out_msg)
{
output_text->append(out_msg);

QTextCursor cursor(output_text->textCursor());
cursor.movePosition(QTextCursor::End, QTextCursor::MoveAnchor);
output_text->setTextCursor(cursor);
QApplication::processEvents();
}

[Chicken Blood Machine]

// with in the basic run I have
for(int x = 0; x < 1000; x++)
{
send(tr("I want more lines\nthis is another line %1").arg(x));
}



What happens if you put a sleep(0) in that loop?

[fellobo]

I placed a dealy for a second and it improved the look of it but still lagged down.

So yes, if I slowed down added/emit call then it will have time to update. I was thinking that maybe the QTextEdit has a lower priority then that of the Thread or even the progress bar for that matter.

I haven't tried it yet but was thinking of placing the thread at a low priority (not sure if this will fix things or even how low to put it.)

Any ideas?

[Chicken Blood Machine]

I placed a dealy for a second and it improved the look of it but still lagged down.


sleep(1) is okay, but I specifically meant sleep(0), this causes the thread to yield to any other running threads and continue execution as quickly as possible. It's a common technique in thread management. Your sleep(1) will cause a 1-second delay between iterations of the loop, even when it is not necessary.

I'm not sure that your problem is to do with threading anyway. It maybe just that QTextEdit cannot handle new data and repainting at the rate that you are sending it. Have you tried using setUpdatesEnabled(bool) to periodically allow the widget to redraw?

[Matt Smith]

I have a huge problem with QTextEdit's performance also. Text editing is a major part of my app and when typing text into a QTE widget, you notice a lag between you typing and the letter appearing. This leads to a reduction in typing accuracy as well. It's very irritating. Trolltech said in the changelog that the widget in 4.1.1 had improved performance, but I don't notice it. (I use Qt/Mac but when using it on X11 similar problems appear.) The problem is sometimes worse than at other times.

[Jojo]

Hello,

I can also confirm the bad QTextEdit performance here on linux.
As said before, sometimes there's just a lag in typing, sometimes there is no lag. The bigger the text gets, the worse the problem. Even 50k or less gets slow here. This is very odd because I have 3.2ghz and a text widget (just showing regular text) shouldn't show any noticable slowdown, even with megs of text inside. Let's just hope 4.2 will fix the issue..