RonMexico
asked on
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.
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.
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.