diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2018-06-20 15:03:57 +0900 |
---|---|---|
committer | Dirk Hohndel <dirk@hohndel.org> | 2018-06-20 16:38:04 +0900 |
commit | 21d6531e457a3c405725a88c42f525425d0831bf (patch) | |
tree | 253ea388a759cf18529651bcdbf52ce890dd6583 /core/pluginmanager.cpp | |
parent | b75eae95c194452499ba73e606c0bc0b41d3fb32 (diff) | |
download | subsurface-21d6531e457a3c405725a88c42f525425d0831bf.tar.gz |
qt-ble: improve responsiveness of waiting for bluetooth data
Our model of waiting for 100ms before re-checking if we got a packet
over BLE resulted in potentially horrendously bad latency for received
packets.
That isn't just a possible performance issue, it actually seems to cause
IO errors with my Suunto EON Core. I'm not entirely sure why, but it
might simply be some timing interaction, particularly since the IO
errors seemed to primarily happen when the dive computer itself was also
busy updating the screen (ie if you pressed buttons on the dive computer
to switch to compass mode, for example).
So replace the silly hardcoded 100ms "waitFor()" function with a
WAITFOR() macro that checks the provided expression every time through
the loop, which gets us a much lower latency (we basically check every
ten milliseconds).
The macro is not beautiful, but it WorksForMe(tm).
This makes a huge difference to the reliability of the download for me,
and might matter for some other dive computers too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'core/pluginmanager.cpp')
0 files changed, 0 insertions, 0 deletions