What is the best way of determining whether or not Qt is checking for user input at a reasonable rate.
-
I have multiple elements on screen and some may lower down performance.
I wanted to ensure that my software stays comfortable to use during these moments, so I decided to use external framerate calculators such as perfstudio and fraps, but it turns out that framerate is not tied with visual updates.
Is there some method of calculating how often Qt checks for input (I assume this happens once per loop)?
And is there a way to ensure the main loop runs on a separate thread if I'm primarily using qml?Thanks.
-
I have multiple elements on screen and some may lower down performance.
I wanted to ensure that my software stays comfortable to use during these moments, so I decided to use external framerate calculators such as perfstudio and fraps, but it turns out that framerate is not tied with visual updates.
Is there some method of calculating how often Qt checks for input (I assume this happens once per loop)?
And is there a way to ensure the main loop runs on a separate thread if I'm primarily using qml?Thanks.
@Hasan-Al-Baghdadi
I don't think "how often Qt checks for input (I assume this happens once per loop)" is how it works.
If by "main loop runs on a separate thread" you mean the UI thread, then that cannot run "separate", all UI operations must be in one main thread. "Separate thread" from what? -
I don't think "how often Qt checks for input (I assume this happens once per loop)" is how it works.
How does it work then, there seems to be a delay if the software is slowing down?
If by "main loop runs on a separate thread" you mean the UI thread, then that cannot run "separate", all UI operations must be in one main thread. "Separate thread" from what?
I meant having all the qml code that runs as a result of UI interactions running on a separate thread from the one that checks for user actions and other signals. As far as I understand this is doable in C++ by creating external threads that manage everything outside of the main UI loop.
-
I don't think "how often Qt checks for input (I assume this happens once per loop)" is how it works.
How does it work then, there seems to be a delay if the software is slowing down?
If by "main loop runs on a separate thread" you mean the UI thread, then that cannot run "separate", all UI operations must be in one main thread. "Separate thread" from what?
I meant having all the qml code that runs as a result of UI interactions running on a separate thread from the one that checks for user actions and other signals. As far as I understand this is doable in C++ by creating external threads that manage everything outside of the main UI loop.
@Hasan-Al-Baghdadi
I'll have to leave it to others who know better than I to comment. But I doubt that anything works by having one thread for output to user and a separate thread for input. I admit I know nothing about QML, but a standard Qt widgets program only has a single thread for everything, UI or not, unless you choose to create extra threads for some reason for your back-end code, and works fine. -
Hi,
What items do make you lose performance ? What are they doing ?
-
@SGaist The strip chart that updates dozens of times a second is the biggest culprit, if a lot of data comes through it could slow the interactivity down.
-
Then you should rather optimise that part to work better. For example optimise the number of updates, the data processing. Maybe move that part to a thread to minimise the impact of processing, etc.
