Page MenuHomePhabricator

Multiple Qt timers overload main thread in Navigation plugins
Closed, WontfixPublic


When starting US imaging and tracking in parallel using the plugins, the Qt timers seem to overload the main thread.

Event Timeline

franza triaged this task as High priority.Sep 27 2018, 8:09 PM
franza created this task.

Moved update code of tracking toolbox to a thread. Works for the moment, with the following problems:

  1. Seems as if the TrackingToolStatusWidget doesn't like if it's updated from another thread. Some buttons in the same UI part are blinking from time to time. If we don't update the widget from the thread there is no problem but we don't see the tool status.
  2. Updating the color of the tool itself (green for valid / red for invalid) is not done at the moment, because some information is missing in the thread. Do we really need this feature?
  3. Update rate is constant for now. The update loop in the thread can wait a certain time if we hand over a update rate from the UI.

I also tried to move the update code of the US plugin to a thread, but it seems as if the USDevice class is not thread safe.

After more test I don't think the Qt timers themselves are the main problem, but multiple update calls to the rendering window from different threads or timers.

A possible solution would be to make the rendering update in a central update loop. I made a test implementation in the mitk::RenderingManager.

Tested MITK Workbench - Some findings and suggestions documented

Version used - V2018.04-beta - VS 2015 - Win32 - US Telemed - Polehmus Tracking

  • The rendering of the ultrasound was good when having lower frame rate for 3D and higher number for 2D view. We tested it with having 20 frame limit for 2d and 5 frames for 3D.
  • Tested with Epiphan Frame grabber and found that the resolution of image is high making rendering slow.
    • Suggestions- To find a way to reduce the resolution of the image being grabbed from Epiphan.
  • The surface files used for the display of tools are huge which might also cause the update to slow down. An idea is to try using different surface files, smaller files.
  • On startup of the Echotrack plugin there are two ultrasound image rendered. The code has to be cleaned up to remove one of the image. But a quick fix is to disable the check box "Update Image automatically" in US plugin "Options" tab.
  • Currently the tracking and ultrasound timers are updated separate and combined modality calls update rendering, which forces too many timers in parallel. Restructuring of code to call rendering update only once for the combined modality might help . Initial test implementation is in branch T25478-RenderingManagerContinousUpdate. More tests are needed to verify this.

I think the main problem is the 3D rendering update. With the suggestions written down in the last comments we can however reach about 20 fps which is ok for the demos. We wont fix this now.