4

I am using a QTextEdit, and I update the text (specifically setHTML) at a 1Hz rate.

Initially the setHtml method is fast (only a few ms); but after 12 hours of running, it takes 256 ms for setHTML to return, the data is a simple table with 5 columns and 10 rows.

This increase continues the longer the program runs.

Does anyone understand what is going on? And, more importantly, how can I make it stop?

Basically what I am doing is:

// get the start time
boost::posix_time::ptime start_time = boost::posix_time::microsec_clock::universal_time();

display->setHtml(text);

boost::posix_time::ptime end_time = boost::posix_time::microsec_clock::universal_time();

boost::posix_time::time_duration time_diff = end_time - start_time;

m_renderTimeDebug = double(time_diff.fractional_seconds() / 1000 );
std::cout << "DRAW TIME; took " << m_renderTimeDebug << " ms " << std::endl;

example here link

Jmussemann
  • 51
  • 8
  • 1
    Is your `text` the same (size) in every run? – m7913d May 25 '17 at 18:53
  • yes, its the exact same text – Jmussemann May 25 '17 at 20:58
  • Could you provide a full code of your test? And, do you really need `QTextEdit`? Is it enough to display html without edditing possibility? – Dmitry Sazonov May 26 '17 at 11:17
  • @DmitrySazonov it does not need to be edited, in fact i call setTextInteractionFlags(Qt::NoTextInteraction), to prevent editing. is there another control i can use? – Jmussemann May 26 '17 at 17:34
  • You may try next workaround: render a html to a `QPixmap` and directly display it in any widget: http://doc.qt.io/qt-5/qtextdocument.html#drawContents – Dmitry Sazonov May 29 '17 at 07:53
  • I added a button that would destroy then recreate the QTextEdit. Once this is done, the draw time drops back down to 0-1 ms, why is this happening? – Jmussemann May 30 '17 at 14:57
  • the code can be found here [QtDrawIssue](https://github.com/jmussemann/qtDrawIssue) – Jmussemann May 30 '17 at 19:53
  • Your example doesn't compile, there are several unsolved conflicts. – cbuchart May 31 '17 at 16:30
  • @cbuchart you were correct, I am new to git and I had some conflicts with updating the project. everything has been resolved and not it complies, please try again – – Jmussemann May 31 '17 at 18:42
  • I've being running the example at 100 Hz for 7 hours and the time is always below 1 ms. I'm using Qt 5.6.1 in VS 2010. I haven't tested with 5.8 since there are no pre-built binaries neither for 2010 nor 2017 (my other compiler). Try with Qt 5.9.0 (LTS), that was released yesterday, to see if it is a bug of 5.8. As I couldn't reproduce your problem I find not useful to test it with 5.9.0 since any negative result (time < 1ms) is not conclusive. – cbuchart Jun 01 '17 at 10:19
  • I downloaded 5.9 last night and re ran the test was was able to confirm the problem is gone. What ever the issue was, it must has be put in sometime after 5.6, and then fixed in 5.9. – Jmussemann Jun 01 '17 at 15:16
  • simple question, is `undoRedoEnabled` enabled? if yes than this is source of your problems. The history of changes has grown to much. – Marek R Jun 01 '17 at 16:26
  • @Marek_R The first thing i did after seeing this issue was to disable, that had no effect on qt 5.8 – Jmussemann Jun 01 '17 at 16:57

2 Answers2

1

I found that this issue has been resolved in Qt 5.9.

I am assuming this was found by the Qt guys and fixed. I have written a defect against Qt 5.8 QTBUG:61137

Jmussemann
  • 51
  • 8
0

Could be a memory leak. Are you allocating new memory to hold your text or somewhere else in your program? You can easily find out using e.g. valgrind if you're on a unix compliant system or a debugger. Is you process image getting bigger over time too?

Rolf Winter
  • 525
  • 3
  • 7
  • possibly, but i doubt it. the Qstring text is created on the stack(QString text) and the "display" is a member pointer assign in the constructor. I can try running with valgrind tonight. This problem showed up during conversion from Qt4.8.7 to Qt 5.8 – Jmussemann May 25 '17 at 18:06
  • ran over the weekend, there does not seem to be a memory leak, after the weekend the draw time was up to 768 ms. – Jmussemann May 30 '17 at 14:53
  • There's a bunch of things you might want to fix in order to make the whole thing faster (less copies etc.). Instead of a std string stream, you might want to use a QTextStream. That will save you the conversion to a C-style stream inside setHtml and the implicit calling of a QString constuctor. Also, you could use the QElapsedTimer while where at it, that will save you using boost. – Rolf Winter May 31 '17 at 08:46
  • I am sure there are things I could do, but why does the sethtml take longer and longer. No matter how much I optimize the code around the sethtml call, sethtml still has an issue. run the program for yourself overnight and you will see. – Jmussemann May 31 '17 at 14:43