User interface blank Windows 10 with new Intel driver 26.x.x.x

[Tom Goddard]

The following bug report has been submitted:
Platform:        Windows-10-10.0.18362
ChimeraX Version: 0.91 (2019-10-30)
Description
Starting ChimeraX all Qt user interface elements are blank (white) when new Intel 26.x.x.x is used on Windows 10.

OpenGL version: 4.6.0 - Build 26.20.100.7323
OpenGL renderer: Intel(R) HD Graphics 530
OpenGL vendor: Intel

[Tom Goddard]

The problem disappears if no QWebEngineView widgets are part of the main window (e.g. Log, File history). The help panel QWebEngineView does not cause the problem because it is not docked -- but docking it in the main window turns the whole gui white.

This problem was reported with VTK.

​https://discourse.vtk.org/t/intel-uhd-620-vtk-qt-bug-with-new-drivers-on-windows/1694

There work-around is to use some QVTKOpenGLNativeWidget instead of their QVTKOpenGLWidget. Probably the difference is that the former does not use QOpenGLContext.

The VTK post mentions Qt logs makeCurrent() fails. Possibly the entire Qt interface goes blank because the QWebEngineView does a makeCurrent() using its own OpenGL context which fails for some reason and QWebEngineView ignores the failure and then attempts to render with the Qt GUI opengl context, corrupting the state of that context.

[Tom Goddard]

Here’s another Qt app where GUI is busted with latest Intel drivers

​https://invent.kde.org/kde/kdenlive/issues/277

[Tom Goddard]

New driver version 7372 released 10/31/2019. Might want to update to that. Driver in this bug report was 7323 from 10/18/2019.

[Conrad Huang]

I tried to install it, but it was "not validated for this computer." I currently have 26.20.100.7262.

[Tom Goddard]

There is no reason to expect the newer driver to fix our problem -- it is only 2 weeks newer.  I read about quite a few bugs with recent Intel driver last night and that makes me think more that this is probably not a Qt problem, it is probably an Intel driver bug, not just undefined behavior.

[Tom Goddard]

Tests in today's ChimeraX daily build show that the Qt GUI starts blank if the ChimeraX graphics rendering QOpenGLContext is created and context.makeCurrent(w) is called. If it is created but makeCurrent is not called then the GUI displays correctly. If makeCurrent is called and immediately after context.doneCurrent() is called then the GUI is blank.

So no OpenGL calls to render the scene are needed to cause the GUI to go blank.

If the log is not shown at startup and the File History thumbnails are not shown by commenting out the FileHistory constructor in ui/gui.py then the GUI works and models are rendered. If the Log is shown the GUI becomes blank, and hiding the Log does not fix the GUI. If instead of showing the log (which is a QWebEngineView) I show the Help Viewer (menu Help / User's Guide) then the help browser comes up as a separte QWebEngineView windows and the GUI works. But as soon as the help viewer is docked to the main window the GUI goes blank.

So the ingredients to cause this bug appear to be 1) ChimeraX QOpenGLContext.makeCurrent() on main window, and 2) a QWebEngineView docked in main window.

The QWebEngineView may be using an OpenGL context (not sure about that), and it may be using it from a different thread. The use from a different thread may be important. ChimeraX normally has two QOpenGLContexts, one for status line and one for the scene rendering and those 2 context alone do not cause the blank GUI.

We believe Qt renders its GUI with its own OpenGL context. Also I have read that there is a Qt GUI thread. Not sure if that is the same thread that we render our OpenGL in.

When the Qt GUI is blank, ChimeraX continues to correctly render the scene. So only Qt's OpenGL rendering is broken, not the ChimeraX OpenGL rendering.

[Tom Goddard]

One idea is that the QSurfaceFormat required by QWebEngineView is different from the QSurfaceFormat obtained by ChimeraX to draw the scene. I tried using the QSurfaceFormat.defaultFormat() and compatibility OpenGL context and the bug behaved the same with OpenGL 4.6.0 compatibility context.

[Tom Goddard]

I tried making the ChimeraX graphics pane a separate top level window and then the GUI renders correctly with the log QWebEngineView shown provided the status line does not use OpenGL.

[Tom Goddard]

I tried rendering scene and status line using makeCurrent() on the top level window instead of the child QWindows we create. That does not show the GUI blanking bug but of course the OpenGL then clobbers other widgets in the top level window. I used Basic Actions for the QWebEngineView in these tests.

This agrees with Greg's observation that QOpenGLWidget does not show this bug in a test program. The Qt docs say QOpenGLWidget does not use its own native window (QWindow) but instead renders to an off-screen framebuffer and then uses glViewPort() to map that to the proper region of the top-level window.

So it appears that the ingredients for this bug are a QWebEngineView in the same top level window as a native subwindow (QWindow) that we use to render OpenGL.

[Tom Goddard]

Driver build versions that don't work 6859 (VTK), 6951 (#2513), 7000 (VTK, Simon Esneault), 7323 (#2537), and that do work 6617 (#2440), 6708 (VTK, Simon Esneault).

So the bug seems to have appeared after 6708 and before 6859.

[Tom Goddard]

Since the bug seems to be related to QWebEngineView using OpenGL on the top level window while ChimeraX uses OpenGL on child native windows I tried making QWebEngineView use child native windows. This is easy to do by calling the QWidget.winId() method which creates a native window for that widget. This fixes the blank GUI bug, although the QWebEngineView windows often have black titlebars (with black title text so unreadable) and and a thin black strip along the right edge. This is seen on the Log panel and file history thumbnail pane (overlaying the grapics pane). These artifacts are tolerable until Intel fixes their driver.

I added code to check if Intel graphics driver with build > 6708 is being used and in that case make native child windows for all our HtmlView (QWebEngineView) widgets. Actually it only makes the native child widgets for HtmlView made after the graphics is checked. The graphics is checked pretty late at startup because the main window has to be shown before OpenGL can be used. On the one machine I have to test on this did not pose a problem. If early HtmlView creations cause problems we may need to try to retroactively create a native child window for them.

I also had ChimeraX issue a warning about this problem if the bad driver is detected.

[Tom Goddard]

Worked around bug as described in previous comment. Some black titlebar artifacts will be present on effected machines. A warning is issued.

Currently all Intel graphics drivers with build > 6708 on Windows get this work-around. In the future when Intel fixes the problem we should make the code not apply to work-around for fixed drivers (ie. add an upper bound on build version that needs the fix).

The fix is in ui/graphics.py in GraphicsWindow._check_for_bad_intel_driver()