The attached batch file (http://www.na-mic.org/Bug/file_download.php?file_id=1631&type=bug) can be copied in the same location as Slicer.exe and can be used to start Slicer through a remote desktop connection (it terminates the connection and starts Slicer, the user then can reconnect and use Slicer).

The user should at least get a meaningful error message. Maybe the workaround batch file could be included in the installation package.

There are other remote desktop clients that don't prevent Slicer startup (for example, Slicer can be started using TeamViewer) - either because they don't use GPU hardware acceleration (just copy the screen content) or support higher OpenGL versions.

From Ken: Microsoft only supports opengl 1.4 in their remote desktop. They would need to use a different remote desktop type app such as VNC/Nomachine.

I guess we could detect the OpenGL version and gracefully warn the user ?

Yes, the main issue here is that the user has no idea why Slicer crashes and what he can do about it.

Not that if Slicer is already started then it works correctly through Windows RDP. So, it might be also possible to make Slicer work by changing initial VTK OpenGL checks.

I'm able to remote desktop into a Windows 10 system (build 10586.589) then start and use a Slicer OpenGL2 build, complete with GPU volume rendering. I tested with client machines running Windows 10 and Ubuntu 16.04 (using Remmina remote desktop client).

Still, with older Windows versions, or if it fails for another reason, clearly Slicer should give some indication to the user of what went wrong.

@lassoan Which version of Windows are you using?

I have the same Windows version, but Slicer still does not start.

When I'm connected to a Windows 10 Enterprise system (version 1511, OS build 10586.589) using Windows remote desktop client (mstsc) then Slicer (and ParaView) still crashes without any error message when I attempt to start it.

@Andras: Do you have two video cards on your system ?

No, just one, GeForce GTX 570. Have you tried mstsc from a Windows computer to another? Maybe Remmina does something special.

Sorry my previous message wasn't clear--Remmina is Linux-only. On the Windows 10 client I used mstsc.

My computer was upgraded to:
OS Name Microsoft Windows 10 Enterprise
Version 10.0.14393 Build 14393

The problem is still the same. Slicer still crashes on startup when loggin in through mstsc.

Do you run your Windows on a virtual machine that has RemoteFX enabled?

In my case Windows is running natively. One difference that might be relevant is that I'm using a Quadro K2200.

Yes, Quadro may make a difference (https://gridforums.nvidia.com/default/topic/346/general-discussion/opengl-and-rdp/).

It seems that we have several workarounds (use Quadro, use different remote desktop protocol, start the application using the attached batch file and reconnect). None of them is very easy or convenient, but probably most use cases are adequately covered. So, I think the only thing we miss is display of a meaningful error message (with a link to a webpage where workarounds are described) when insufficient OpenGL support is detected.

Just a note, I've recently seen the same issue with other software (chrome and firefox running WebGL). They crash if started during a remote desktop connection but you can start them natively and then connect once they are running.

This pull request aims for a more graceful handling of OpenGL insufficiency: https://gitlab.kitware.com/vtk/vtk/merge_requests/2812

This looks like it will also help: https://gitlab.kitware.com/vtk/vtk/commit/29607014a2dea0931ff30c0b584b25f760233245

Should we close the issue ?

following r27104, the following is integrated:

    * kitware/VTK@a7988f5 (from Francois Budin <francois.budin@kitware.com>)
      OpenGL2: Check that context exists before trying to pop context.

        On some linux drivers (such as nvidia version 384.111 and 387.34) setting the
        context to zero causes a segfault so check before setting in cases where the
        destruction may be trying to pop to a zero context.

and following r27080 the following was integrated:

    * kitware/VTK@51e0dc9
      vtkOpenGLRenderWindow: Improve error message reported when OpenGL is not supported.

        Unable to find a valid OpenGL 3.2 or later implementation.
        Please update your video card driver to the latest version.
        If you are using Mesa please make sure you have version 11.2 or
        later and make sure your driver in Mesa supports OpenGL 3.2 such
        as llvmpipe or openswr. If you are on windows and using Microsoft
        remote desktop note that it only supports OpenGL 3.2 with nvidia
        quadro cards. You can use other remoting software such as nomachine
        to avoid this issue.

        See https://issues.slicer.org/view.php?id=4252

Otherwise, did someone try to build with VTK_USE_OPENGL_DELAYED_LOAD set to ON ?

Parallels on Mac has very poor OpenGL support (https://forum.parallels.com/threads/opengl-3-2.290841/page-2, as of today, it still only supports only OpenGL2.1). Therefore, recent Slicer versions, which use OpenGL2 rendering backend cannot run on a Parallels virtual machine.

Potential solutions:

• Use native MacOSX build on Mac computers.
• VMWare Fusion has better OpenGL support, so it may be possible to run Slicer on that, but this has not been confirmed yet. The VMWare virtual machine may need some configuration tuning to actually have access to recent OpenGL API version.

This is still an issue on windows remote desktop. I just tested the 2018-04-09 build and the application crashes with no indication of why.

If we cannot fix the underlying issue then we should at least detect it and display the warning text in a dialog.

Ping on this: is there a way to detect this situation and display a dialog instead of crashing? Or maybe better, offer to restart slicer in 10 seconds, allowing a remote desktop user to disconnect and then reconnect after 30 seconds or so.

I've just tested running Slicer via remote desktop using current Windows 10 Professional on both client and server side, with Intel integrated GPU: Slicer run perfectly, including volume rendering; OpenGL Extensions Viewer tool reported exactly the same OpenGL capabilities as when running natively.

I've tested this with an integrated Intel GPU. Others have reported similar success with NVidia Quadro cards, but some reported issues with NVidia GeForce (https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop).

So, it seems that the problem will be getting less and less serious. I don't think that it is worth at this point to implement any fancy mechanism (dynamic switching between OpenGL backends, etc.), but there are still many old computers out there, so at least we should display a meaningful error message and quit instead of crashing.

"So, it seems that the problem will be getting less and less serious. "

It would be great if this problem went away, but it's still an issue when using Microsoft's remote desktop app for mac.

It appears from the windows forum pages that something like this would disconnect the remote desktop and start Slicer, but the user would need to re-connect to remote desktop.

tscon 1 /dest:console
start "C:\Program Files\ .. \Slicer.exe"

If we agree this is the best workaround for now we should add this info to the wiki. It would be even better if the launcher could detect the situation, inform the user, and automatically perform the workaround.

I'll add OpenGL version detection and popup display (based on Paraview's implementation) when OpenGL capabilities are insufficient. I have a prototype that works just needs some polishing.

In the popup, I could add a link where users can find more information (explanation, solutions, workarounds). Where this link should point to?

I've only ever found random forum posts on this topic, so no good link comes to mind.

I think the most useful thing for the popup to do is offer to restart Slicer after a 5 second delay (with a tooltip that says to use this if you are on a remote desktop and to disconnect immediately and reconnect in 15 seconds or so).

What about creating a "Remote Desktop" category in the Slicer FAQ ? Or the VTK wiki (https://www.vtk.org/Wiki/VTK/Tutorials) ?

I'll add it to General section of FAQ (where installation and general issues are discussed).

Sounds good. Thanks for tackling this.

I've implemented all that we've discussed about - see https://github.com/Slicer/Slicer/pull/1026

On my linux workstation, it reports that "Graphics capability of this computer is not sufficient to run this application" without more details

Screenshot from 2018-10-04 18-59-41.png (31,581 bytes)

Unfortunately, it seems that capabilities reporting only works if minimum requirements are met. "Hide details" button size seems off, too (it looks good on all Windows machines that I've tested on).

Does ParaView reports OpenGL problems on startup?

Steve, could you please test the behavior on Mac and on your Windows virtual machine? I've fixed reconnection feature a couple of minutes ago, I'm not sure it's included in the nightly build (https://github.com/Slicer/Slicer/commit/34d30ec1bb110babadd94ebd8cc4ebd3f7ca1074).

Dashboard indicates that OpenGL error is detected on Mac, too (http://slicer.cdash.org/testDetails.php?test=9191470&build=1392052).

The mechanism works well on Windows but seems to be too sensitive on Linux & Mac. I'll disable it for Linux & Mac until somebody has time to investigate on these platforms.

Makes sense to disable it on Linux and macOS.

Otherwise, on Paraview after starting a server (./bin/pvserver) and connecting to it .. it displays that the server has no Headless capabilities (which is expected given the build option)

Screenshot from 2018-10-05 11-58-52.png (73,203 bytes)

"Hide details" button size seems off, too (it looks good on all Windows machines that I've tested on).

It seems the difference in button size is explained by https://github.com/Slicer/Slicer/blob/a335e39f30bdd75b7af7dd2b5b58b0ef68104e76/Base/QTGUI/qSlicerStyle.cxx#L130-L134

Setting the value to 16 give all the button of the same size .. but their all small

@jcfr Is the rendering check failing on your computer because off-screen rendering is not supported? Would you be able to step through the code and see where the check fails?
Anyway, I'll disable the check on Linux and Mac, so if you don't have time to investigate this now then we can come back to it later.

I don't think there is an issue. Assuming "off-screen rendering" is the same thing as "headless rendering", it is not supported without building with some specific option. This is why X11 is required.

See https://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D

I don't think off-screen and headless are the same. Off-screen rendering is rendering to a window that is not displayed on screen (you may still have GPU and a display attached). Headless rendering refers to rendering without a connected display, maybe even without physical video card.

Off-screen rendering is a pretty basic capability so your computer should be able to do it. Could you see if you can adjust the checking mechanism (maybe skip some steps) to make it work?

Agreed. And since paraview code checks for "headless" support ... and the code in Slicer is doing the same, it is expected to fail on linux without building against the correct library.

Could you see if you can adjust the checking mechanism (maybe skip some steps) to make it work?

If think on linux, we should just report the capabilities and not show a popup.

If think on linux, we should just report the capabilities and not show a popup.

The issue is that VTK crashes (at least on Windows) if capabilities are no met. You don't get a chance to check capabilities if you wait until the application startup is completed.

FYI, I've disabled check on Linux and Mac in r27458.

@lassoan - it's close but it seems it's not waiting long enough to retry. Here's what happens:

1) connected to Windows machine (windows 10, nvidia 1080) via RDP using mac Microsoft Remote Desktop app. If a Slicer session was already running before the connection it works normally.

2) Start Slicer nightly 2018-10-07

3) Insufficient graphics capability dialog opens.

4) click Retry

5) Admin privileges dialog comes up, click Yes

6) RDP disconnects.

7) reconnect and Insufficient graphics capability dialog is open

Clicking Retry again takes me back to step 4 and the whole thing can be repeated.

It seems the restart happens before the disconnect is finished. I'll try adding a 10 second wait and we'll see if that fixes it in tomorrow's nightly.

Let's see if this fixes things:

https://github.com/Slicer/Slicer/commit/537c2d429480dd7f1744e0f3138257e82d283401

I'll test tomorrow.

Ooops, I committed directly to github by mistake. Commit via svn succeeded in overwritting the previous commit so all looks good.

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27462

https://github.com/Slicer/Slicer/commit/ff136a0fed0506299393befa3f043e75fefa89b0

It worked as it was (without a delay) on one computer that I tested on, but I would not be surprised if you had to add a few-second delay.

This fix should just wait until the disconnect has completed, so no extra delay should be needed.

@pieper, it looks good. Let us know if it worked for you. I've tested your latest changes and it still works on the computer where it worked before (as expected).

@jcfr, This page gives a very clear description of offscreen/headless rendering: https://kitware.github.io/paraview-docs/latest/cxx/Offscreen.html

Thanks Andras - I will check. It looks like the nightly build is not (yet?) available on download.slicer.org or the dashboard.

Steve, you can try this Slicer installer: https://1drv.ms/u/s!Arm_AFxB9yqHtbRwmIC4_pOonVeyIg (built by perklab.factory tonight).

Yes! The download from Perklab worked (on the same mac where yesterday's failed) so I'd say this is good.

This page gives a very clear description of offscreen/headless rendering: https://kitware.github.io/paraview-docs/latest/cxx/Offscreen.html

The missing piece of information is the option VTK_USE_OPENGL_DELAYED_LOAD which is off by default.