title: Current state and solutions for OpenGL over Windows Remote
body: <h1>OpenGL and Windows Remote don't play along nicely.</h1>
  <p>Solutions for this are dependent on the use case and answers are fragmented across the vast depths of the net.
  This is a write-up I wish existed when I started researching this, both for coders and non-coders.</p>
  <h2>Problem:</h2>
  <p>A RDP session of Windows does not expose the graphics card, at least not directly. For instance you cannot change the desktop resolution and GraphicsCard drivers usually just disable their setting menus. Starting a OpenGL context higher than v1.1 fails because of this. The, especially in support IRCs, often suggested &quot;Don't use WindowsRemote&quot; is unfortunately not an option for many. In many corporate environments Windows Remote is a constantly used tool and an app has to work there as well.</p>
  <h2>Non-Coder workarounds</h2>
  <p>You can start the OpenGL program, allowing it to see the graphics card, create an opengl context and then connect via WindowsRemote. This always works, as Windows remote just transfers the window content. This can be accomplished by:</p>
  <ul>
  <li>A batch script, that closes the session and starts the program, allowing you to connect to the program already running. (<a href="https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS" rel="noreferrer">Source</a>)</li>
  <li>Using VNC or other to remote into the machine, start the program and then switch to Windows Remote. (<a href="http://tightvnc.net/" rel="noreferrer">Simple VNC programm</a>, also with a <a href="https://portableapps.com/node/32118" rel="noreferrer">portable client</a>)</li>
  </ul>
  <h2>Coder workarounds</h2>
  <p>(Only for OpenGL ES)Translate OpenGL to DirectX. DirectX works under Windows Remote flawselly and even has a Software rendering fallback built into DX11 if something fails.</p>
  <ul>
  <li>Use the ANGLE Project to do this at run-time. This is what QT <a href="https://wiki.qt.io/Qt_5_on_Windows_ANGLE_and_OpenGL#Recommendations" rel="noreferrer">officially suggests</a> you do and how Chrome and Firefox implement WebGL. (<a href="https://github.com/google/angle" rel="noreferrer">Source</a>)</li>
  </ul>
  <p>Switch to software rendering as a fall back. Some CAD software like 3dsMax does this for instance:</p>
  <ul>
  <li>Under SDL2 you can use SDL_CreateSoftwareRenderer (<a href="https://wiki.libsdl.org/SDL_CreateSoftwareRenderer" rel="noreferrer">Source</a>)</li>
  <li>Under GLFW version 3.3 will release OSMesa (Mesa's off screen rendering), in the mean time you can build the Github version with -DGLFW_USE_OSMESA=TRUE, but I personally still struggle to get that running (<a href="http://www.glfw.org/docs/3.3/window_guide.html#window_hints_ctx" rel="noreferrer">Source</a>)</li>
  <li>Directly use Mesa's LLVM pipe for a fast OpenGL implementation. (<a href="https://www.mesa3d.org/llvmpipe.html" rel="noreferrer">Source</a>)</li>
  </ul>
  <p>Misc:</p>
  <ul>
  <li>Use OpenGL 1.1: Windows has a built in implementation of OpenGL 1.1 and
  earlier. Some game engines have a built in fall back to this and thus
  work under Windows Remote.</li>
  <li>Apparently there is a middle-ware, that allows for even OpenGL 4 over Windows Remote, but it's part of a bigger package and is a commercial solution. (<a href="http://www.thinanywhere.com/products/thinanywhere-for-windows-rdp/" rel="noreferrer">Source</a>)</li>
  </ul>
  <p>Any other solutions or corrections are greatly appreciated.</p>
  <p>[10] Nvidia -&gt; <a href="https://www.khronos.org/news/permalink/nvidia-provides-opengl-accelerated-remote-desktop-for-geforce-5e88fc2035e342.98417181" rel="noreferrer">https://www.khronos.org/news/permalink/nvidia-provides-opengl-accelerated-remote-desktop-for-geforce-5e88fc2035e342.98417181</a></p>