Since I have been working with the workbench, the 2D rendering of (video) streams is relatively slow. In the workbench framerates between 5 and 15 FPS are common and often not acceptable. I am not sure about the component of this bug. It might change when I learn more.
Here is what I know so far:
-Reproducible with MITK-ToF, which replaces the data of an mitkImage (1 slice) constantly via a ToF-Camera
-Reproducible with MITK-US, which replaces the data of an mitkImage (1 slice) constantly via a WebCam or an US-device (both Linux and Windows)
> The pipeline how to generate the data does not matter (much) and it is not OS related
I wrote the following test applications:
a. Viewer app creating N mitkRenderWindows and streaming data.
b. Viewer app creating N QmitkRenderWindows and streaming data.
c. Viewer app creating N QmitkRenderWindows and streaming data with BlueBerry.
d. A RenderWindow added to the mitkWorkbench.
For testing purposes I used a 640x480 RGB stream. The framerates (FPS) for 1 Renderwindow are for the Apps 1.-4.:
a. 40, b. 40, c. 20, d. 10
> The Mitk Rendering seems to be reasonable fast for at least a single QmitkRenderwindow. Currently, BlueBerry or something that comes with it seems to have a huge impact.
The Framerates drop a lot for 4 Renderwindows:
a. 12, b. 10, c. 5, d. 4
> Rendering in multiple Renderwindows has a huge impact.
Since the QtEvent pipeline is assumed to influence the performance, I tried to remove all interaction from renderwindows by adding and empty event method to the QmitkRenderWindow like this:
protected: bool event( QEvent* /*e*/ ) {return false;}
This disables all interaction with renderwindows, but does not significantly increase the framerate (+2 FPS in the App d.).
> QtEvent pipeline seems to have no major impact.
I also did some profiling on the workbench without major insights. The profiler mainly reveals endless class of VTKs rendering methods which seems to be correct.