What's the fastest way to display some text in Qt?

Wings · 12 Jun 2015, 04:17

@vtduong What's QTextBox?? I couldn't find that in the documentation. I'm using Qt 5.4, by the way.

JKSH · 12 Jun 2015, 04:50

@Wings said:

@vtduong What's QTextBox?? I couldn't find that in the documentation. I'm using Qt 5.4, by the way.

I think he meant QLineEdit.

Anyway, the Console will update text much faster than any widget.

a text is displayed for about 10-30 ms.

That's very short. May I ask why you want to update the text so quickly? Are you sure the user can read at that speed?

Wings · 12 Jun 2015, 05:08

@JKSH Thanks, but mine is a GUI application. And yeah, the text should be updated very quickly because it's about subliminal messages - at the border of conscious perception. Did that sound spooky? :D

Anyway, I don't believe QLineEdit is any faster than QLabel. Is it?

JKSH · 12 Jun 2015, 05:56

@Wings said:

@JKSH Thanks, but mine is a GUI application. And yeah, the text should be updated very quickly because it's about subliminal messages - at the border of conscious perception. Did that sound spooky? :D

Sounds pretty cool! :D Psych experiment?

Anyway, I don't believe QLineEdit is any faster than QLabel. Is it?

I don't know, sorry; I've never tried updating text at that speed. But I'm guessing it wouldn't be faster. The best way to find out is to try it.

Also try:

The Graphics View Framework, with QGraphicsSimpleTextItem
Qt Quick 2

Wings · 6 Dec 2015, 05:57

@JKSH said:

Sounds pretty cool! :D Psych experiment?

LOL no! It'll be a self development application and I'll release it soon, for free!

The Graphics View Framework, with QGraphicsSimpleTextItem

I read that QGraphicsSimpleTextItem should be added to a QGraphicsScene. Looks pretty low-level. I hope things don't get very complicated there. I'm already very inclined to over-engineer things. Anyway, I'll give a shot. Thanks for the pointer (and also for imagining me doing some "Psych experiment" :D).

KiwiJeff · 12 Jun 2015, 13:19

Out of curiosity, but how are you actually measuring the time? It sounds like something I might want to check out myself.

Wings · 12 Jun 2015, 20:59

@KiwiJeff said:

Out of curiosity, but how are you actually measuring the time? It sounds like something I might want to check out myself.

Right now I'm using a Qt::PreciseTimer type QTimer. But, probably I'll move to one with <10ms resolution.

Wings · 6 Dec 2015, 13:23

This post is deleted!

JKSH · wrote on 12 Jun 2015, 14:09

@Wings said:

Oh! I wanted to close this thread, instead I deleted the question!!! Great.

Restored :)

JKSH · 12 Jun 2015, 17:27

@Wings said:

I read that QGraphicsSimpleTextItem should be added to a QGraphicsScene. Looks pretty low-level.

Yes, people often use low-level tools in order to gain higher performance.

Also have a look at Qt Quick. It is GPU-accelerated, which might help.

Thanks for the pointer (and also for imagining me doing some "Psych experiment" :D).

You're welcome!

When I was a student, I earned a bit of pocket money signing up as a test subject for psych experiments, designed and run by psychology PhD students. Sound spooky? ;-) (those experiments often involved reacting to shapes and colours on a computer screen)

Wings · 6 Dec 2015, 17:42

Reading http://code.woboq.org/qt5/qtbase/src/widgets/widgets/qlabel.cpp.html#273 (thanks @JKSH for the link) helped. Looks like doing setTextFormat(Qt::PlainText) prevents Qt from guessing the type of text (when it comes to milliseconds, everything counts).

@JKSH said:

Also have a look at Qt Quick. It is GPU-accelerated, which might help.

I'll try that soon. But, I've realized that I was making a very fundamental mistake in understanding my problem. The mistake is, my timer will anyway start only after the text is completely drawn (i.e. after setText() returns). So, the resolution of the timer is actually the crucial factor here. If the timer provides microsecond (or at least low-millisecond) resolution, accurately, the clear() slot will be called (almost) exactly after the required number of milliseconds. Then, the required subliminal behavior can be obtained. I hope I'm able to explain my mistake clearly. And I also hope someone else on Earth is benefited from this (Martians not allowed).

When I was a student, I earned a but of pocket money signing up as a test subject for psych experiments, designed and run by psychology PhD students. Sound spooky? ;-) (those experiments often involved reacting to shapes and colours on a computer screen)

This one really sounds a little spooky! :D

P.S.: I'm impressed by the friendliness of the Qt community. So, all my Qt questions will now be redirected from www.stackoverflow.com to forum.qt.io.

Chris Kawa · 6 Dec 2015, 18:11

Spooky or not you can't really go faster than what the display can handle. Most consumer grade displays tick at (or around) 60Hz, which means one frame takes about 16.6ms. Updating any faster than that is just wasting CPU. A percentile of the users (like 3D Vision gamers or some graphics professionals) might have a higher frequency displays which ticks at around 100 or 120Hz, but they are extremely rare at best.

Wings · wrote on 12 Jun 2015, 18:14

@Chris-Kawa

Thanks. That's something I didn't pay attention to. Then, I guess I should set the lower limit to something around 16ms (is 17ms safe enough?).

Chris Kawa · 6 Dec 2015, 18:31

@Wings said:

is 17ms safe enough?

Absolutely not. Any fixed interval generally isn't. I intentionally said "or around". It's common for displays to refresh at 59.XX - 60.YY Hz.
If you fix your interval at 17ms (assuming you can be that precise, which you generally can't anyway) you are ending at an update for example every 17/16.63 of frame. Of course the display won't wait for you if you're late like that, so even if you miss the refresh 0.0001ms you will skip a frame and you will see visible stutter or other artifacts.

UI controls like line edits or labels are not designed to be high-frequency or latency free controls and as so they don't care that much to be "frame-perfect". They can skip a frame or two if they need more time to format their content (especially something like rich text).

If you want high frequency display you should do your own painting. Eaither with classes mentioned by JKSH or simply drawing with QPainter in paintEvent. The general idea is you don't try to "chase" refresh rate of the display. Draw your stuff and schedule next update (read update() and repaint() docs and the differences). If you need to, you can check how much time passed since last draw (e.g. with QElapsedTimer) but don't try to schedule draws at regular intervals. You WILL fail ;) Graphics drivers and OS scheduler will make sure you do at least some of the time ;)

Wings · wrote on 12 Jun 2015, 18:50

@Chris-Kawa

If you want high frequency display you should do your own painting...

What's the point in doing high frequency drawing if the display's refresh rate is itself around 60Hz? You yourself said that let however fast my drawing might be, nothing can be drawn anything on screen faster than ~16.6ms.

Chris Kawa · 6 Dec 2015, 18:58

By high frequency I meant those 60Hz. This as opposed to just setting a text in a UI widget, which is not reliable to achieve even that.
The difference is that with your own drawing you can make sure you are ready every frame the display displays. Setting text in a UI widget is just telling it to update it but it will do so only when it is ready to do so, which is out of your control.

KiwiJeff · W Wings 12 Jun 2015, 13:19

@Wings said:

@KiwiJeff said:

Out of curiosity, but how are you actually measuring the time? It sounds like something I might want to check out myself.

Right now I'm using a Qt::PreciseTimer type QTimer. But, probably I'll move to one with <10ms resolution.

I was afraid I would get an answer like that. I mean, you are more or less guessing the speed inside the system, while your use case is to have a preserved speed. All you know in the end is the time between the "sure, put the text up" and the "sure, clear the text" and not the actual time on the screen? Of course, if this time is lower when using the QPainter/QML rather then setText, I would go for that.

In the end, I think the only way to know if your software works for your use case is to have a high speed camera. And, as mentioned in other replies, a calibrated system.

Chris Kawa · 15 Jun 2015, 16:13

@KiwiJeff said:

In the end, I think the only way to know if your software works for your use case is to have a high speed camera.

What would you need a high speed camera for? 60Hz is not that much and you can see every frame with your own eyes if you focus enough. If you want to analyze the frames you can always use a screen recording software. If you're an owner of not that old Nvidia graphics card you can even use the built in ShadowPlay feature to record your app and analyze frame by frame. Invaluable tool for such tasks.

Q139 · wrote on 13 Jun 2015, 11:03

You could use timer and force gui update to update gui faster than standard optimization.
If screen 100fps then every 5-10 ms maybe fast enough.
Human preception probably less , only thing i get if watching movies over 40 fps is moving smoothness and relaxes eyes more.

Chris Kawa · 10 May 2019, 15:09

@Q139 The whole point is not to do more work than the display can handle. Just cause you update faster than the screen refreshes doesn't mean you're getting a better result. Let me visualize this:

The black vertical bars is the v-sync (hardware refresh points).
The red bars is the drawing and the light red bars is the drawing that will never make it to the screen.
The arrows point to data that will be used for given refresh.

As you can see drawing faster than refresh rate is not good at all. You will skip irregular amounts of frames. If you tried to animate an object with this approach it would appear very "jumpy", skipping ahead or falling behind. It's very uneasy on the eyes.

Drawing just a little slower than the refresh (17ms) seems to be good at first, but notice that every few frames a frame will be displayed twice (because the new update is just a little late). This will look like an animated object is moving in bursts. Staying for two frames in place and then going steady for few next. Not good at all.

The above example doesn't take into account that the drawing does not always take the same amount of time (the rectangles vary in width frame to frame). Also neither the timer ticks nor the v-sync is performed in perfect intervals so the red rectangles and black bars can move slightly causing even more havoc. And then there's also an issue of double buffering which will make all this even worse.

The correct approach is to not use a timer at all. Wait for v-sync and draw then. This is good for couple of reasons:

we're not wasting cpu on drawing anything more than necessary.
we don't care how often the refresh is done. We just always paint for the next one and don't try to "fit just right in".
we never skip a frame (important if you're going to display something for one frame only).
since we're starting to draw just after the refresh we have the whole cycle for ourselves to draw, so it doesn't matter if drawing takes 3ms in one frame and 11 in another. With timer you need to make sure you're "just in time" for refresh, which is basically impossible to assure.