Page MenuHomePhabricator

Mouse Move events during startup can cause application freeze
Closed, ResolvedPublic


The application freezes during startup when one produces mouse move events when the workbench still initializes the application but the render windows aren't initialized yet (show white color). A mouse move event is passed down to a render window in order to perform a picking. In vtkOpenGLRenderWindow the app freezes in vtkOpenGLRenderWindow::GetZbufferData(...):

// Error checking
// Must clear previous errors first.
while(glGetError() != GL_NO_ERROR)

because the opengl context isn't properly setup yet and errors are returned.

Slicer had the same problem [1][2] a long time ago and state that they have fixed it in ctk [3]. They also had the

The right solution IMO would be to add a check in QmitkRenderWindow to only map 2D to 3D position in case the renderer is initialized. Otherwise the event handling doesn't make sense either, right?

A version update of QT might solve the issue but it also is about how and when to use the rendering environment. I have asked a qhile ago in the users list if anybody else has these problems and got no answer. Here all my colleagues are blocked by this! They have to restart the application and wait until they finally come through to the fully initialized workbench. Thus I will work on a solution in my fork and send a pull request once it is solved.

;) Best,

mitk version 2015.05.0 (extended by minor customizations [4]) with all external toolkits as defined in superbuild.
QT 5.4.0
NVIDIA driver 353.82 (newest)






	vtkRenderingOpenGL-6.2d.dll!vtkOpenGLRenderWindow::GetZbufferData(int x1, int y1, int x2, int y2, float * z_data) Line 1440	C++
	vtkRenderingOpenGL-6.2d.dll!vtkOpenGLRenderWindow::GetZbufferData(int x1, int y1, int x2, int y2) Line 1477	C++
	vtkRenderingCore-6.2d.dll!vtkRenderer::GetZ(int x, int y) Line 1218	C++
	vtkRenderingCore-6.2d.dll!vtkWorldPointPicker::Pick(double selectionX, double selectionY, double selectionZ, vtkRenderer * renderer) Line 50	C++
	MitkCore.dll!mitk::VtkPropRenderer::PickWorldPoint(const mitk::Point<double,2> & displayPoint, mitk::Point<double,3> & worldPoint) Line 384	C++
	MitkCore.dll!mitk::BaseRenderer::Map2DRendererPositionTo3DWorldPosition(const mitk::Point<double,2> & mousePosition) Line 315	C++

MitkQtWidgets.dll!QmitkRenderWindow::mouseMoveEvent(QMouseEvent * me) Line 171 C++

	Qt5Widgetsd.dll!QWidget::event(QEvent * event) Line 8649	C++
	vtkGUISupportQt-6.2d.dll!QVTKWidget::event(QEvent * e) Line 413	C++
	Qt5Widgetsd.dll!QApplicationPrivate::notify_helper(QObject * receiver, QEvent * e) Line 3722	C++
	Qt5Widgetsd.dll!QApplication::notify(QObject * receiver, QEvent * e) Line 3280	C++
	MitkAppUtil.dll!QmitkSafeNotify<QApplication>(QApplication * app, QObject * receiver, QEvent * event) Line 31	C++
	MitkAppUtil.dll!QmitkSafeApplication::notify(QObject * receiver, QEvent * event) Line 36	C++
	Qt5Cored.dll!QCoreApplication::notifyInternal(QObject * receiver, QEvent * event) Line 932	C++
	Qt5Cored.dll!QCoreApplication::sendSpontaneousEvent(QObject * receiver, QEvent * event) Line 231	C++
	Qt5Widgetsd.dll!QApplicationPrivate::sendMouseEvent(QWidget * receiver, QMouseEvent * event, QWidget * alienWidget, QWidget * nativeWidget, QWidget * * buttonDown, QPointer<QWidget> & lastMouseReceiver, bool spontaneous) Line 2751	C++

Event Timeline

I have to add that we have a message box at the beginning of the workbench to confirm that it is not for clinical use. I can't reproduce the issue in the mitk workbench! Thus decreasing sevirity.

Added message box to mitk workbench ans till couldn't reproduce the issue. So I guess our workbench has a different startup setup than the mirkWorbench has. Thus once more decreasing severity and adapting title.

Reproduction in MITK workbench:

I had a look into this issue. It can be reproduced using the regular MITK workbench when adding a call like

QMessageBox::information(NULL, "Hello", "Here I am");

to org_mitk_gui_qt_application_Activator::start(), just after the QmitkRegisterClasses().

When doing so, this puts Qt into a state (did not figure out details) where our QmitkRenderWindow can receive mouse move events before it has first rendered. Seemingly, such a state is avoided when the workbench main window is the first Qt windows that becomes visible.

The problem:

When mouse move events are processed before a render window has first rendered will make calls to vtkOpenGLRenderWindow::GetZbufferData() (in order to translate a 2D mouse position into a 3D position for the interaction framework.

Proposed solution:

Since the problem could be hit from multiple paths and not only from mouse moves, I added a check to mitk::VtkPropRenderer::PickWorldPoint() that immediately returns if the renderwindow has not yet rendered. This minimal change works fine and solves the observed application freeze.

User maleike has pushed new remote branch:


User maleike has pushed new remote branch:


(In reply to Git Admin from comment #4)

User maleike has pushed new remote branch:


This one for integration as bugfix to the 2015.05 release branch

(In reply to Git Admin from comment #5)

User maleike has pushed new remote branch:


This one for integration into master (automatic merge conflicted)

[742d49]: Merge branch 'bug-19306-freeze-on-application-start-MASTER'

Merged commits:

2015-09-10 17:25:38 Daniel Maleike [b115f9]
Never pick in before first rendering has finished