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



  • I am developing an application where I need to display some text real fast. A precise timer issues a "draw string" command and a text is displayed for about 10-30 ms. So, I need a fast way to render text on the screen. I am currently using a QLabel, but it's not able to handle that speed, hence it fails to draw the text several times. The quality of the render is not very important. The text should just be readable, that's all. How can I get the desired speed? Or maybe, is there any way in which I can get good enough speed from QLabel?



  • Have you tried using a QTextBox instead?

    Or another way is two have two labels, have one show while the other disappears. it will give the impression that it's faster.



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


  • Moderators

    @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?



  • @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?


  • Moderators

    @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


  • @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).


  • Banned

    This post is deleted!


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



  • @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.



  • This post is deleted!

  • Moderators

    @Wings said:

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

    Restored :)


  • Moderators

    @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)



  • 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.

  • Moderators

    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.



  • @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?).


  • Moderators

    @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 ;)



  • @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.


  • Moderators

    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.



  • @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.


  • Moderators

    @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.



  • 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.


  • Moderators

    @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 mi visualize this:

    v-sync

    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.


  • @Chris-Kawa
    I disagree. What you are recording with ShadowPlay is what is send out to the monitor, but not what the monitor is actually showing. Maybe the more advanced monitors with HDMI or DisplayPort will have a 1:1 representation, but then you are still assuming the monitor itself displays everything it receives.


  • Moderators

    @KiwiJeff said:

    What you are recording with ShadowPlay is what is send out to the monitor, but not what the monitor is actually showing. Maybe the more advanced monitors with HDMI or DisplayPort will have a 1:1 representation, but then you are still assuming the monitor itself displays everything it receives.

    Well... yes, yes i do. Are you saying a display will skip frames or otherwise loose pixels? I find it hard to believe. Can you back this up with some official information? I would be interested to know more details if that's true.
    Of course I totally agree in terms of stuff like color representation or artifacts like ghosting, but skipping frames?



  • @Chris-Kawa

    Well, in games, when you don't have V-sync enabled, you see tearing. I consider this skipping part of the frame. I have no official information on actual skipping of frames in modern 60 hz monitors.

    Either way, the actual point that I wanted to make is that you can not trust information from within the system to know what is preserved outside the system. The speed indication in the car and the actual speed of the car are almost always slightly off.

    Nevertheless, we are going off topic and this thread has already shown good ways of measuring techniques, so I suggest we close it for now :).



  • This post is deleted!


  • @KiwiJeff said:

    Nevertheless, we are going off topic and this thread has already shown good ways of measuring techniques, so I suggest we close it for now :).

    I don't think that's off topic. It's actually my mistake that I neglected this thread by marking it solved, prematurely. Many thanks to you and @Chris-Kawa for providing valuable input. :) I'll remove the "SOLVED" prefix because it is still not solved. I have questions and I'll irritate you again. :D



  • Okay, so I studied @Chris-Kawa's answer again. And what hit me like a bolt of lightning is that what I was dreaming of doing is virtually nonsensical. Now I really understand what he was saying.

    This is what I wished to make happen (when I was naive :D):

    • The background timer's timeout event, issues an update() command which draws immediately into the screen (like magic), which in turn, triggers a ~17ms single-shot timer.
    • When that timer's timeout occurs, the text shown on the screen is cleared immediately (again magic).
    • This keeps on looping till the user stops the background timer.

    This is what actually happens:

    • Issue an update() command that "draws" the text (text is NOT shown yet). The single-shot timer (@~17ms) is triggered.
      ...probably some milliseconds elapsed (let this be x ms).
    • At the vertical refresh moment, text becomes visible on screen. (this is damn fast, so I'm ignoring this interval)
      ...probably some milliseconds elapsed (let this be y ms)
    • The single-shot timer has ended after ~(x+y) ms and a command to clear the text has been issued.
      ...probably some milliseconds elapsed (let this be z ms).
    • At the vertical refresh moment, text is cleared from the screen. (ignoring this interval again)

    So, the user sees the text for about (x+y+z+k) ms where, k is the sum of the additional milliseconds used in actually doing that stuff. Now, x+y+z+k ms is almost always not equal to the desired interval.
    That's why, this process sucks, big time.

    Now, this is the best that can happen:

    • Wait for the background timer to end. After it ends, as soon as a refresh cycle occurs, issue the command to draw the text.
    • At the next refresh cycle, the text will be drawn to the screen. After the text is drawn, start the single-shot timer.
    • After the timer has ended, issue the command to remove the text. Wait for the next refresh cycle.
    • At the next refresh cycle, the text will be removed from the screen. Now, start the background time. Now go to the first step.

    Visualizing the process,
    please enable images

    Now, it is evident that showing the text exactly for 15ms is impossible using the previous method. But at least we can make sure that we don't show that more than ~32ms. And that's good news. At least in my case.

    Now, the point is how to achieve that. I don't know. But I'll find you and I'll kill you, nay implement you.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.