• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 802
  • Last Modified:

In Qt, How to prevent rendering from killing other periodic functions?

(I see there are "Top QT Experts" to the right -- but is there a zone??)

Hello, we are fairly new to QT, and writing an embedded QT application (using QTQuick) that talks to a serial port (needs to send messages at a constant rate) and renders some complex, scrollable displays.

We have found that the user can use the display (for example, scrolling the chart) in a way that makes the serial messages stop for a bit. We believe that the scrolling/re-rendering is starving the timer that is driving the serial messages momentarily. Currently this is driven by a QTimer and a signal/slot connection.

We need to revise to ensure that the rendering of the display, no matter how complex, cannot prevent the sending of a serial message. What's the best way to do this in a QT application? We can make the display simpler, but this would simply reduce the chances of this -- if there is enough data to render this it seems this is always possible with our current approach -- we want this to not be possible.

I can imagine answers ranging from setting priority flags (if any) in the QT framework, to re-sourcing our serial comm from the QT Timer to something more deterministic, to making our application multithreaded (I hope it doesn't get this drastic, but we will do this if it's the only way to ensure serial cant be interrupted).

Any thoughts from experienced QT folks are very appreciated.
0
RonMexico
Asked:
RonMexico
  • 2
1 Solution
 
irfan_omairCommented:
He He he ,... Making it multitrheaded is not Drastic :)
Blv me that is the best way to keep GUI thread separate from your functional processing thread.  in my experience separating GUI thread (which is always rendering thread) is not more than an hour job.
But dont forget to communicate between GUI thread and worker thread using signal and slot this is best non blocking way , you may also use PostMessge but i think former would be better.

Best of luck.
0
 
RonMexicoAuthor Commented:
Hm, I am presuming it would be drastic because UI calls a lot of functions of the backend directly, would have to rewrite ALL of these to protect using sync objects, wouldn't we?  Any shortcuts here?

I'll do a little research, but does QT multithreading allow us to prioritize relatively, so that rendering can never starve out the serial?

Thanks for the help.
0
 
irfan_omairCommented:
i can understand if there are really several calls between GUI and worker then this could be little time consuming to separate it, But dont you think in such situation multithreading should have been considered really at design time?
if GUI is having so much dependency on worker thread then in all Framework/toolkit the best way to go for is only and only this (mulitithread).

and Yes you can prioritize it with Qt. I again emphasis on one thing communication between these thread is damn important, choose signal slot is the best way to go.

Best fo Luck
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now