I have checked with a prototyp to just move also the core of the generator to an own thread. It helps to make the UI more responsive. BUT it is not enough because the UI (workbench) thread and all other threads must kept seperated, using Qt mechanisms, we need to use a lot of signal/slot and this seems to keep the UI thread (event loop) very bussy.

I have the feeling, that it is better to move for the core generator implementations to std threading mechanisms and not using Qt at all in order to avoid the Qt event loop completly.
In this context I also think we should rethink the generator concept, to use more internal scheduling/controll loops and less triggering by event (storms). The first event based "wake up" and check was nice and somewho elegant on paper, but it just does not scale in practice as we see now.

+ We should ignore node changes, that are deletions of statistic nodes and check if we can detect if the deletions are caused by cleaning the storage due to application closure. Background: With the protoype tests it seems to some time s slow down the shut down, because the deletion of nodes triggered the generator to produce them again. This only stopped after the input nodes where also removed. Would be good if we can avoid it with a concept.

Was able to reduce the delay to an reasonable size by making the event filtering in QmitkImageStatisticsTreeModel and the Qmitk data generation classes more specific.

So far they where triggered to often e.g. by simple changes of irrelevant properties of the node (e.g. vor visualization).
I think it is now fast enough. If not we can reopen the issue.