search

shadow1runner / qgroundcontrol

QGroundControl Ground Control Station with Obstacle Detection
https://bitbucket.org/shadow1runner/uavobstacledetection/
Other
0 stars 0 forks source link

UI is too slow wrt. frame display #38

Closed shadow1runner closed 8 years ago

shadow1runner commented 8 years ago

While the OwnFlow processing seems to be ok-ish (speed-wise):

Frame # 176
Measured FoE:
    ( 86 ,  81 )
    Inliers:  472  /  200000    0.236 %
Frame # 177
Measured FoE:
    ( 88 ,  86 )
    Inliers:  552  /  200000    0.276 %
Frame # 178
Measured FoE:
    ( 99 ,  82 )
    Inliers:  780  /  200000    0.39 %
Collision level lowered by 1 to  6
Emitting collisionLevelChanged(), new collision level:  6
Frame # 179
Unknown command 11
Measured FoE:
    ( 99 ,  82 )
    Inliers:  663  /  200000    0.3315 %
Collision level raised by 1 to  7
Emitting collisionLevelChanged(), new collision level:  7
Frame # 180
Unknown command 11
Measured FoE:
    ( 104 ,  82 )
    Inliers:  728  /  200000    0.364 %
Collision level raised by 1 to  8
Emitting collisionLevelChanged(), new collision level:  8
Frame # 181
Unknown command 11
Measured FoE:
    ( 103 ,  85 )
    Inliers:  732  /  200000    0.366 %
Collision level raised by 1 to  9
Frame # 182
Unknown command 11
Measured FoE:
    ( 97 ,  85 )
    Inliers:  849  /  200000    0.4245 %
Collision level lowered by 1 to  7
Emitting collisionLevelChanged(), new collision level:  7

It is not in the UI (neither the persisted frames on the SSD, which have the same amount of frames): Only 139 images out of 287 according to log file are displayed.

shadow1runner commented 8 years ago

It seems that it's really only the UI which is 'that' slow, maybe it's QML interworking? The analysis have shown that the signal/slot connections are executed asap, and the FramePersister has an ok-ish number of persisted frames -- except for UI

shadow1runner commented 8 years ago

Acc. to these quick stats:

GP: # 1 QDateTime(2016-05-26 15:35:50.773 UTC Qt::TimeSpec(UTC))
DP: # 1 QDateTime(2016-05-26 15:35:50.773 UTC Qt::TimeSpec(UTC))
Collision level lowered by 1 to  1
Emitting collisionLevelChanged(), new collision level:  1
GP: # 2 QDateTime(2016-05-26 15:35:51.052 UTC Qt::TimeSpec(UTC))
DP: # 2 QDateTime(2016-05-26 15:35:51.069 UTC Qt::TimeSpec(UTC))
Collision level lowered by 1 to  0
GP: # 3 QDateTime(2016-05-26 15:35:51.152 UTC Qt::TimeSpec(UTC))
DP: # 3 QDateTime(2016-05-26 15:35:51.158 UTC Qt::TimeSpec(UTC))
Collision level lowered by 1 to  0
GP: # 4 QDateTime(2016-05-26 15:35:51.255 UTC Qt::TimeSpec(UTC))
DP: # 4 QDateTime(2016-05-26 15:35:51.264 UTC Qt::TimeSpec(UTC))
Collision level raised by 1 to  2
Emitting collisionLevelChanged(), new collision level:  2
GP: # 5 QDateTime(2016-05-26 15:35:51.365 UTC Qt::TimeSpec(UTC))
DP: # 5 QDateTime(2016-05-26 15:35:51.365 UTC Qt::TimeSpec(UTC))
Collision level raised by 1 to  3
Emitting collisionLevelChanged(), new collision level:  3
DP: # 6 QDateTime(2016-05-26 15:35:51.463 UTC Qt::TimeSpec(UTC))
GP: # 6 QDateTime(2016-05-26 15:35:51.463 UTC Qt::TimeSpec(UTC))

(GP: OwnFlowGrapher, DP: OwnFlowDataProvider) the signals are indeed raised at almost the same moment -> does rendering take so long?

shadow1runner commented 8 years ago

-> idea: don't render UI stuff in main thread, but add an additional render layer in between, this should reduce the workload on the UI thread, it has better things to do anyway...

shadow1runner commented 8 years ago

The QML refreshes at:

DP "AVG/MIN (#9)/MAX (#2) in ms FOR `QML Refresh Rate` after 142 iterations:\t389.546 ms\t67.4756 ms\t26655 ms\n"

equal to: avg/min/max fps: 2,567 / 14,820172033 / 0,037516413

shadow1runner commented 8 years ago

TBD: Compare the call ratings of FramePersister with CADataProvider (as well as with the emitting signals in UiFramePreparer