You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that some systems manage to consistently saturate USB HS bandwidth when downloading logs while others struggle to utilize 1/3rd of the available bandwidth. Some cursory digging leads me to believe this is a performance issue with performing mavlink decoding and log download on the UI thread.
We should rework the LogDownloadController to handle the actual download process on a worker thread, and consider the scope of work to move communications and mavlink parsing onto a worker thread as well.
The text was updated successfully, but these errors were encountered:
I've noticed that some systems manage to consistently saturate USB HS bandwidth when downloading logs while others struggle to utilize 1/3rd of the available bandwidth. Some cursory digging leads me to believe this is a performance issue with performing mavlink decoding and log download on the UI thread.
We should rework the LogDownloadController to handle the actual download process on a worker thread, and consider the scope of work to move communications and mavlink parsing onto a worker thread as well.
The text was updated successfully, but these errors were encountered: