http://public.kitware.com/pipermail/vtk-developers/2014-May/014998.html

Great, thank you!

[0e420e]: Merge branch 'bug-18553-fix-linux-depth-buffer'

Merged commits:

2014-12-17 16:28:58 Marco Nolden [b38c33]
Fix depth buffer problems on linux

Move from QVTKWidget to QVTKWidget2. Patch contributed bz Rostislav Khlebnikov

User kislinsk has pushed new remote branch:

bug-18553-Fix

[3edeea]: Merge branch 'bug-18553-Fix'

Merged commits:

2014-12-17 17:08:48 Stefan Kislinskiy [59fd42]
COMP: Added missing header file.

Windows output during Workbench startup:

0.21 core.io.log: Logfile: C:/Users/Stefan/AppData/Local/DKFZ/MITK Workbench_266
8232127/data/13/mitk-0.log
void cdecl QWindow::setTransientParent(class QWindow *) QWidgetWindow(0x3a2ace
0, name = "QWidgetClassWindow") must be a top level window.
void cdecl QWindow::setTransientParent(class QWindow *) QWidgetWindow(0x3a2ace
0, name = "QWidgetClassWindow") must be a top level window.
void cdecl QWindow::setTransientParent(class QWindow *) QWidgetWindow(0x3c6afb
0, name = "QWidgetClassWindow") must be a top level window.
void cdecl QWindow::setTransientParent(class QWindow *) QWidgetWindow(0x4033e5
0, name = "QWidgetClassWindow") must be a top level window.
void __cdecl QWindow::setTransientParent(class QWindow *) QWidgetWindow(0x6ffecc
0, name = "QWidgetClassWindow") must be a top level window.
0.46 blueberry.ui.wrkbncPlg: LOG: Warning: Detected recursive attempt by part or
g.mitk.views.datamanager to create itself (this is probably, but not necessarily
, a bug)
0.56 blueberry.ui.wrkbnc: BlueBerry Workbench ready
QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefi
ned
QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefi
ned
QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefi
ned
QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefi
ned

I believe this is related to this:
https://bugreports.qt-project.org/browse/QTBUG-42360

Just to keep it in mind for Qt 5.4:
http://stackoverflow.com/questions/26944831/using-qvtkwidget-and-qopenglwidget-in-the-same-ui

@Rostislav

During the last month we gathered some experience (and fixed a few newly introduced bugs) regarding the usage of QVTKWidget2 instead of QVTKWidget. However, we are not able to fix major issues which arises from the migration, since they are either VTK-specific or even driver-specific.

Examples are:

• Always warnings in Windows, sometimes OpenGL-related errors and even crashes
• Unable to start the workbench at all on some Mac OSX versions (crashes)
• Very low performance compared to QVTKWidget on some Linux distros (also tested in standalone VTK applications)

tl;dr:
The old solution works on all our machines, except a single one (in which case the zBuffer error is related to known driver issues on Intel Graphics (probably NVidia Optimus) notebooks (also your setup?). Hence, we want to go back to QVTKWidget as the issues are nearly a blocker at the moment.

I understand. I actually tested this on Ubuntu 14 machine and it definitely fixed the z-buffer issue that I had there - I'm not sure which GPU is there though. Similarly, it fixed the issue in Ubuntu running in virtual box.

I still have the warnings in windows, but everything seems to work correctly.

I tried to dig into removing these warnings, but it seems that it's not really possible without quite big changes to VTK. What I read is that you cannot do any OpenGL rendering until the first exposeEvent() is called, but this relies on the QWindow class which was introduced in Qt5 (as opposed to QWidget). Perhaps, the next VTK version will have this issue fixed (also, a big rendering system overhaul seems to be going in VTK and it will be awesome: http://www.kitware.com/source/home/post/144).

User kislinsk has pushed new remote branch:

bug-18553-RevertToQVTKWidget

[777e3f]: Merge branch 'bug-18553-RevertToQVTKWidget'

Merged commits:

2015-01-21 15:25:07 Stefan Kislinskiy [7a6d57]
Revert base class from QVTKWidget2 to QVTKWidget.

Yes, let's hope the rendering system overhaul of VTK will fix some OpenGL-related stuff, as the current system is antiquated anyways. The current solution sadly was a little bit too pragmatic. :-)

I close this bug as we pointed out that the actual issue is an external driver bug.

Pushed new branch T18553-QVTKWidgetFixForzBufferIssue.

I'll test it on Windows, wait a sec. :-)

@kolbch Okay, works.