Page MenuHomePhabricator

[statistics] Logic of DataGeneratorBase blocks the UI thread
Open, HighPublic


Status: When a several images and ROIs are selected (leading to >40-50 combinations), the checking of valid combinations and their status consumes considerable time and is retriggerd with every new results. As this is currently done by the DataGenerater class itself and in the UI thread, it practically freezes the whole UI. Not good!

I think the best way is to move all the checking, monitoring and spawning logic into its own thread.

Event Timeline

floca triaged this task as High priority.Aug 6 2020, 11:47 PM
floca created this task.
floca moved this task from Backlog to Statistics on the MITK (2020) board.

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.