Part of that is surely the 3D rendering which is happening again (although it should never be done). I'll first try to remove this behaviour and then see how long the tests take.

Part of this bug (slowdown) is that RenderingManager forces 3D updates every
time ANY renderwindow is updated. QmitkSliceBasedSegmentation's functionality
testing generates a lot of 2D window updates, which is normally quite fast.
Only the 3D rendering of the used contours is quite slow.

In RenderingManager.cpp line 279 an update of all 3D windows is generated when
there are more than 1 3D-renderwindows and at least one does . MainApp with all
functionalities contains now at least 3 3D-renderwindows (ReportGenerator,
DesignGalleries, MultiWidget)

Opened a bug for Jens/Mathias

An attachment showing the input image and interaction that leads to the application using all the memory it can get. The problem is inside tmGetContour8N, where an infinite loop is started

Input image for tmGetContour8N

circle * new tmGetContour8N
o.ooo
.o..o
o.ooo
ooooo
oooo.

The algorithm first adds the top-left point to the result-set, then adds all the "." points counter-clockwise. The abort criterion is that a point is added, which is equal to the first point in the result set. This just never happens in this case.

Ok, error source found. The method tmGetContour8N should get a first memory offset that IS PART of the segmentation. This was never guaranteed. Actually it's quite surprising, that the code worked so often.

I'll check all calls of this function...