The first step is to analyze the behaviour of qThread and qTime. I want to know how accurate the timing is (does the thread wake up after the specified time) and how much time the train/track/station operations take. I've done this by adding some qDebug statements:
For an interval of 100 ms, the output is:
The time difference between "BEFORE EMIT" and "AFTER EMIT" is almost always 0 ms, so the estimated time consumption for emitting stepTimeSignal command can be neglected.
The time between "BEFORE SLEEP" and "WOKE UP" is between 1 ms up to 15 ms more than expected. This is a minor issue, but the target time tends to drift as the small delays accumulate. The solution to this behaviour is the following code change:
In this case, the interval is 100 ms. The system configured for low performance and the build is debug. |
In this case, the interval is 20 ms. The computer is set to have high performance and the build is release, the operations take 2-3 ms. It seems that the time intervals are irregular. |
In this case, the interval is 20 ms, but the operations take 30 ms. The next signal is trigged as soon as the former is done. The behaviour is expected. |
The time consumption is far below one millisecond. This means that QML will be critical for optimizations. |
- Display the simulated time
- Show the time needed for stepTimeForNetwork, as a percentage of the intervals
- Replace the two time spinboxes with one spinbox for fast forward factor and add a button that will toggle between "play" and "pause".
Further, I need to investigate if it is possible to make the QML operations run without affecting the performance of the train operations.
No comments:
Post a Comment