The cause for this problem lies in missing state-transitions of the interaction state-machine. DisplayConfigPACS.xml defines the events based on which the state-machine in DisplayInteraction.xml acts. For modifier-based interactions, a MousePressEvent / MouseReleaseEvent in combination with a modifier-key are responsible to transition into / out of the corresponding state ("move", "zoom", ...). When the modifier-key is released BEFORE releasing the mouse button, the second event is never triggered, causing the state machine to get stuck in that specific state, which blocks most other interactions.

Thanks for your reply!

My conclusion / suggestion so far:

1. RenderingManager::RequestUpdate*-functions add render windows to a list of render windows to be re-rendered, where re-rendering means updating the graphics / pixel (OpenGL)
2. RendereringManager::InitializeView*-functions (changed to RenderWindowManager::InitializeView* in D517) update the Time- / Slice-Navigation controller and the camera controller to a specific view ("field of view").

This is related to T28464.

I know that there is a problem with Windows / OpenGL using MITK remotely. I just had never seen this particular error-message given in the description. I will ask about the latest release and an updated driver, thanks!

• Does the problem also occure with the current release?
• It is a known problem that Windows (OpenGL problem) does not work (well) remote with MITK. The best way is installing the right drivers (see https://phabricator.mitk.org/T26427#224676)

The point is: I'm removing the InitializeView*-functions from the RenderingManager to separate the repsonsibilities. For these functions to work I now want to pass the RenderingManager as an argument - but this is not working with an IRenderingManager, which I get returned by the mentioned classes.

I cannot answer that question directly. As I do not know the history of this class and documentation does not help. Maybe @nolden does.

I changed all occurrences of the InitializeView*-functions and built different MITK configurations to be sure not to miss anything.

Deleted branch from rMITK MITK: release/T28602-2021-Week-26.

Pushed new branch to rMITK MITK: release/T28602-2021-Week-26.

All InitializeView*-functions do not need anything from the RenderingManager except for the list / vector of render windows and the time navigation controller - both can be retrieved via public functions. I started separating the rendering functions from the view resetting functions to have two distinct classes with clearer responsibilities.

It is important to understand the differences between the following functions:

• RenderingManager::RequestUpdateAll
  • basically goes through all the registered render windows and calls RenderingManager::RequestUpdate on each one
• RenderingManager::RequestUpdate
  • sets the status of the given render window to "RENDERING_REQUESTED" and generates a rendering request event
  • QmitkRenderingManager::GenerateRenderingRequestEvent
    • this is an implementation of the abstract function which simply adds a QmitkRenderingRequestEvent to Qt's post event queue. If the event queue is processed and a QmitkRenderingRequestEvent::RenderingRequest is detected, RenderingManager::ExecutePendingRequests is called
  • RenderingManager::ExecutePendingRequests
    • goes through all the registered render windows and calls RenderingManager::ForceImmediateUpdate on each one that has the status "RENDERING_REQUESTED" set
  • RenderingManager::ForceImmediateUpdate
    • here the actual rendering is initiated by calling vtkWindow::Render on a given render window

For a more thorough investigation of possible side-effects I will list the occurrences of similar code and see if the mentioned solution could be applied there.
I already started doing that some time ago in T26496: [mxn multi widget] Re-initializations reset all render windows and will continue there:

In T26496, @kalali wrote:

I propose to first gather different actions which lead to an update request.

Just for testing purposes: I created an additional Enum value to mitk::RenderingManager::RequestType, called NO_UPDATE. I'm using this new value inside QmitkSegmentationView::CreateNewSegmentation, for the call mitk::RenderingManager::GetInstance()->InitializeViews(referenceImage->GetTimeGeometry(), mitk::RenderingManager::NO_UPDATE, true);.

Task for a long-term solution: T27613: Improve reinit behavior

The active render window can be selected using the render window manager but it is not possible to do it the other way around - clicking inside a render window does not activate this render window.

I just tested the latest mxn multi widget on develop and now the render window menu icons have a thick border around them - which does not look nice. Need to find out how this happened.

If I remember correctly I created a new renderwindowtreemodel, based on QmitkAbstractDataStorageModel because I could not reuse the classic tree inspector. Reason for this was probably mainly the different handling of data nodes for specific render windows. I will re-recheck this within the next weeks and probably come back to you for consultation ;)

This is then based on the QmitkDataStorageTreeInspector? Would make sense, wouldn't it?