Servo: Nightly build opens a blank window just a few seconds and closes

[gaby2300]

Downloaded nightly build from: https://download.servo.org/nightly/windows-msvc/servo-latest.msi
Running servo.exe opens a blank window just a few seconds and closes.

@jonathandturner is trying to help me

[gaby2300]

@jonathandturner - I filed the issue and I would appreciate your help!

I don't know why someone closed it :(

[batmont]

can't enjoy new render engine too
I've tried on 3 different computers: laptop, pc, tablet pc
7 SP1 64-bit, 7 64-bit and 8.1 64-bit
They're all dual-core Intel CPU (with no Turbo Boost, no Hyperthreading and without virtualization?), and all (or 2 of them) have only integrated GPU (Intel HD Graphics)

[jonathandturner]

@gaby2300 - I'm currently on Easter break for the next four days, but we hope to be able to fix this. It sounds like a few other people are encountering similar issues.

[jonathandturner]

@gaby2300 can you tell us about your setup? What version of Windows are you using? What graphics card? How much RAM does your computer have?

[zeljic]

FYI. The same here, Windows 7 Ultimate 64bit, Intel Integrated Graphics + nVidia. Both drivers are installed. Latest drivers are installed, "standard software installed" chrome, firefox, c++ redistributable (2013/2015). RAM 8Gb. CPU Intel Core i7 2630QM

[gaby2300]

I use Windows 7 Ultimate 64 bit and Intel(R) HD Graphics. My PC has a RAM of 4GB

[voracity]

I've had the same issue since July. I've been trying it on Windows 7 without ever having success. But I also have a Windows 10 system --- initially, that had an identical problem, but it started working with the switchover to MSVC builds.

The Windows 7 system is 64 bit (i7 2630QM), 8GB RAM, Hybrid AMD Radeon/Intel HD 3000 graphics (but have forced to just Intel graphics or just Radeon graphics, and same issues with both). As far as I'm aware, it has the latest Windows updates and drivers for everything.

[NiLSPACE]

Since todays build it also crashes on my laptop. By capturing stdout (which cmd doesn't do by default) I managed to get the error message:

Failed to link shader program: Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.
Type mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.
Out of resource error.

called `Result::unwrap()` on an `Err` value: Link("Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.
Type mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.
Out of resource error.
") (thread main, at src\libcore\result.rs:859)

Specs:
CPU: I7 6500U @ 2.5GHz,
RAM: 16.0GB Dual-Channel,
GPU: Intel HD Graphics 520
OS: Windows 10 PRO 1607

[CAfromCA]

I'm seeing the same behavior: Servo opens for a brief moment, then immediately closes.

When I run from the command line with servo.exe > err.txt 2>&1, this is the content of the output file:

Failed to create window.: OsError("wglCreateContextAttribsARB failed: OS Error -1073274731 (FormatMessageW() returned error 317) (os error -1073274731)") (thread main, at src\libcore\result.rs:859)

That's identical to @NiLSPACE, so this may be a different issue. If anyone knows how to get more verbose logging out of Servo I'm happy to dig deeper.

Specs:
OS: Windows 7 Enterprise SP1 64-bit
CPU: i5 2520M @ 2.5 GHz
RAM: 12.0 GB (11.8 GB usable due to integrated graphics)
GPU: Intel HD Graphics 3000
GPU driver version: 9.17.10.4229

It looks like glutin and Piston have open issues with the same error in wglCreateContextAttribsARB as the one I got from Servo:

https://github.com/tomaka/glutin/issues/515
https://github.com/PistonDevelopers/piston/issues/1035

[lygstate]

So is me.

[wilt00]

I had the same error message as @NiLSPACE above.
The workaround I've found is to manually set servo.exe to use the discrete Nvidia graphics card in my laptop via the Nvidia Control Panel app, and then the program opens and runs (as far as I can tell) normally.

Specs:
OS: Windows 10 Pro 64-bit, version 1703, build 15063.138
CPU: i7 4500U
Integrated GPU: Intel HD Graphics 4400, Driver version 20.19.15.4549
Discrete GPU: Geforce GT 745M, Driver version 22.21.13.8165

[glennw]

@jrmuizel @staktrace Do you guys have any Windows machines in the office with some of the gfx cards listed? I'm thinking most of this would go away if/when Servo starts using ANGLE on Windows, but it'd be nice to repro and do some testing. There might be some simple fixes / workarounds.

[staktrace]

I'll let @jrmuizel respond about the office machines, I'm not sure offhand what they have. It might be worth trying a Firefox nightly build with the gfx.webrender.enabled pref set to true (or just get a QuantumRender build from the graphics branch (e.g. here) and see if it also crashes on startup. It will try to use webrender with ANGLE so if it starts up (or fails to) that might provide some useful information.

[NiLSPACE]

Firefox with Webrender starts without any problem.
I get this from stdout:

WebRender - OpenGL version new OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f)
nsStringStats
 => mAllocCount:          17861
 => mReallocCount:          470
 => mFreeCount:           17861
 => mShareCount:          23239
 => mAdoptCount:           1717
 => mAdoptFreeCount:       1717
 => Process ID: 16428, Thread ID: 7968
nsStringStats
 => mAllocCount:            517
 => mReallocCount:           31
 => mFreeCount:             517
 => mShareCount:            394
 => mAdoptCount:              0
 => mAdoptFreeCount:          0
 => Process ID: 7908, Thread ID: 15292
nsStringStats
 => mAllocCount:          91263
 => mReallocCount:         2348
 => mFreeCount:           91263
 => mShareCount:          68604
 => mAdoptCount:           4079
 => mAdoptFreeCount:       4079
 => Process ID: 10436, Thread ID: 17012

[NiLSPACE]

After updating my Intel GPU drivers from 20.19.15.4483 to 21.20.16.4550 Servo is working again.

[jonathandturner]

Interesting, thanks @NiLSPACE.

For others who are having this issue, can you confirm that you have the latest drivers for your video card? Servo does use your video card quite a bit, similar to video games, so I'm not surprised that you need to keep the video drivers up to date.

[glennw]

Some drivers are having trouble with passing a struct through the VS -> FS interpolators. This PR (https://github.com/servo/servo/pull/16523) contains a workaround for that. When it lands, it should fix some of the issues above.

[Alhaitham]

The workaround by @wilt00 worked for me.

Using the external GPU made Servo start normally.

[CAfromCA]

@jonathandturner I appear to have the latest driver for the Intel HD 3000, which was released in June 2015.

That age is probably not surprising, since Sandy Bridge just turned 6 and Intel discontinued technical support for it in June 2016.

[crlf0710]

I had this issue yesterday but i pulled the newest code and updated my display driver just now.

It's working fine now.

[gaby2300]

I cannot update my video card drivers as my PC is quite old by now.

Could someone explain me what does the gfx.webrender.enabled pref set to
true have to do with Nightly's servo build please? I would greatly
appreciate it! I would also appreciate undesrtanding how to proceed with
the workaround mentioned by Glenn, and how to obtain a QuantumRender build
from the graphics branch.

Many thanks!

On 19 April 2017 at 10:04, CrLF0710 [e-mail] wrote:

I had this issue yesterday but i pulled the newest code and updated my
display driver just now.

It's working fine now.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/servo/servo/issues/16393#issuecomment-295262542, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACDVaDIjO1QxILopkQ_YtTbKzqL7ULjzks5rxgZngaJpZM4M8GHe
.

[NiLSPACE]

WebRender is a component of Servo which is being moved to Firefox as part of the Quantum project. By setting gfx.webrender.enabled to true you tell Firefox to use that. I suggest creating a new profile first in about:profiles as the option is still really unstable.

[jdm]

The 4/19 Servo nightly should include the workaround mentioned by @glennw.

[CAfromCA]

@jdm The nightly installer I downloaded a few minutes ago created files with a timestamp of 1:11am EDT on 4/19. If that timestamp is correct and relevant, it looks like that's about 5 hours prior to PR #16523 being merged.

Is there any way to confirm the build date/time and/or commit pulled for the current nightly?

[gaby2300]

I installed today's build but I still have the same issue

On 20 April 2017 at 05:11, Josh Matthews [e-mail] wrote:

The 4/19 Servo nightly should include the workaround mentioned by @glennw
https://github.com/glennw.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/servo/servo/issues/16393#issuecomment-295624680, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACDVaDidyWJ5w1rZid97-3SGKS_X-koIks5rxxMogaJpZM4M8GHe
.

[gaby2300]

I created a new profile in Nightly, set the pref to true and opened the
browser. The result was a very slow nightly (I tried 2 sites); no close,
resize or minimize button. Clicking the upper right corner resulted in a
minimized browser. Maximizing it resulted red blank window with no tabs.

I have several profiles and the 4 channels installed. Which one should I
change the preference in?

​Thanks for your help!​

On 20 April 2017 at 03:57, NiLSPACE [e-mail] wrote:

WebRender is a component of Servo which is being moved to Firefox as part
of the Quantum project. By setting gfx.webrender.enabled to true you tell
Firefox to use that. I suggest creating a new profile first in
about:profiles as the option is still really unstable.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/servo/servo/issues/16393#issuecomment-295602245, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACDVaJE2k4YWQFN5gj5jazVtNrq7FIvHks5rxwHlgaJpZM4M8GHe
.

[jdm]

That's fine. It was just a check to see if using webrender in Firefox nightly demonstrated the same problem that occurs in Servo when using webrender.

[CAfromCA]

I just re-downloaded the Windows installer and it's the same "1:11 am on 4/19" build that I downloaded a bit over 24 hours ago and then again about 20 hours ago.

I grabbed a copy of the Mac image and the timestamps in there are all 9:11pm on 4/20.

Is there an issue with the Windows build/upload process? Has there been a Windows build since PR #16523 was merged?

In the meantime I'll see if I can build my own copy to confirm whether I'm still crashing.

[cbrewster]

See #16560

[CAfromCA]

Looks like PR #16523 didn't fix my issue. I checked out the latest code from master about 2 hours ago and compiled, but got the same error:

'Failed to create window.: OsError("wglCreateContextAttribsARB failed: OS Error -1073274731 (FormatMessageW() returned error 317) (os error -1073274731)") (thread main, at src\libcore\result.rs:859)'

[jjwhitney]

I'm running into this with Intel HD Graphics 4600. Switching to NVIDIA GeForce GTX 860M (See instructions above by @wilt00) works around it for me.

[ArkadiuszMichalski]

Same here, autoclose when run .exe, my spec:
OS: Windows 7 Enterprise SP1 64-bit
CPU: i7 2600k
GPU: Intel HD Graphics 3000
GPU driver version: 15.28.24.4229 (9.17.10.4229) https://downloadcenter.intel.com/product/81500/Intel-HD-Graphics-3000

[CAfromCA]

If it helps, I did a "--dev" build of the latest code (as of about 10:45am EDT) and got a stack backtrace to go with the error:

Failed to create window.: OsError("wglCreateContextAttribsARB failed: OS Error -1073274731 (FormatMessageW() returned error 317) (os error -1073274731)") (thread main, at src\libcore\result.rs:859)
stack backtrace:
   0:        0x142f1610d - backtrace::backtrace::trace<closure>
                        at C:\servo\servo\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.0\src\backtrace\mod.rs:42
   1:        0x142f0ea03 - backtrace::capture::Backtrace::new
                        at C:\servo\servo\target\debug\build\backtrace-17fa5380aeaf9437\out\capture.rs:79
   2:        0x13f61952d - servo::main::{{closure}}
                        at C:\servo\servo\ports\servo\main.rs:124
   3:        0x143f13590 - std::panicking::rust_panic_with_hook
                        at C:\projects\rust\src\libstd\panicking.rs:550
   4:        0x143f13429 - std::panicking::begin_panic<collections::string::String>
                        at C:\projects\rust\src\libstd\panicking.rs:511
   5:        0x143f13332 - std::panicking::begin_panic_fmt
                        at C:\projects\rust\src\libstd\panicking.rs:495
   6:        0x143f132aa - std::panicking::rust_begin_panic
                        at C:\projects\rust\src\libstd\panicking.rs:471
   7:        0x143f1e008 - core::panicking::panic_fmt
                        at C:\projects\rust\src\libcore\panicking.rs:69
   8:        0x1430d5f99 - core::result::unwrap_failed<glutin::CreationError>
                        at C:\projects\rust\src\libcore\macros.rs:29
   9:        0x14309022b - core::result::Result<glutin::Window, glutin::CreationError>::expect<glutin::Window,glutin::CreationError>
                        at C:\projects\rust\src\libcore\result.rs:761
  10:        0x143097133 - glutin_app::window::Window::new
                        at C:\servo\servo\ports\glutin\window.rs:263
  11:        0x1430b7e03 - glutin_app::create_window
                        at C:\servo\servo\ports\glutin\lib.rs:50
  12:        0x13f618a16 - servo::main
                        at C:\servo\servo\ports\servo\main.rs:141
  13:        0x143f14c62 - panic_unwind::__rust_maybe_catch_panic
                        at C:\projects\rust\src\libpanic_unwind\lib.rs:98
  14:        0x143f13b6a - std::rt::lang_start
                        at C:\projects\rust\src\libstd\rt.rs:51
  15:        0x13f619a7c - main
  16:        0x1447ef459 - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  17:         0x77a359cd - BaseThreadInitThunk
Servo exited with return value 101

[recompileorg]

I have the same problem as everyone else.

OS: Windows 10 Home 64-bit
CPU: Intel Core i3-5010U
GPU: Intel HD Graphics 5500

I'm running the latest driver version from Dell 20.19.15.4531, released 14 Feb 2017. Trying to install the 20.19.15.4624 from Intel warns me against replacing the version from the manufacturer.

Output from servo.exe > err.txt 2>&1:

Failed to link shader program: Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.
Type mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.
Out of resource error.

called `Result::unwrap()` on an `Err` value: Link("Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.\nType mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.\nOut of resource error.\n") (thread main, at src\libcore\result.rs:859)
ERROR:servo: called `Result::unwrap()` on an `Err` value: Link("Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.\nType mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.\nOut of resource error.\n")

[glennw]

Tracked in https://github.com/servo/webrender/issues/1157

[2efPer]

Crashed too.
Intel Core i5-5200U
NVIDIA GeForce 940M
Windows 7 64bit

Failed to link shader program: Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.
Type mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.
Out of resource error.
called Result::unwrap() on an Err value: Link("Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.\nType mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.\nOut of resource error.\n") (thread main, at src\libcore\result.rs:859)

[CAfromCA]

Unfortunately, it looks like servo/webrender#1192 did not fix my issue, though it closed servo/webrender#1157.

I pulled the latest Servo code again this morning and did a fresh --dev build, and it was essentially identical to the one I posted above (other that a few line numbers changing slightly).

Should I open a new ticket for my specific error? If so, should I open it in the Servo or WebRender repo?

For whatever it's worth, I tried to run Servo with the -z command line argument to see if that made a difference, but the process still quits immediately. The backtrace is a little different than the one I get when running Servo normally, so I've included it in case it's interesting.

gl function was not loaded (thread main, at C:\servo\servo\target\debug\build\gleam-596504a3dd4a6e35\out/gl_bindings.rs:953)
stack backtrace:
   0:        0x14270b490 - backtrace::backtrace::trace<closure>
                        at C:\servo\servo\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.0\src\backtrace\mod.rs:41
   1:        0x142703c64 - backtrace::capture::Backtrace::new
                        at C:\servo\servo\target\debug\build\backtrace-6ddf4a4263d5dc15\out\capture.rs:79
   2:        0x13f24b1b8 - servo::main::{{closure}}
                        at C:\servo\servo\ports\servo\main.rs:123
   3:        0x143c845c0 - std::panicking::rust_panic_with_hook
                        at C:\projects\rust\src\libstd\panicking.rs:550
   4:        0x1439bb3f9 - std::panicking::begin_panic<&str>
                        at C:\projects\rust\src\libstd\panicking.rs:511
   5:        0x1439bc394 - gleam::ffi_gl::missing_fn_panic
                        at C:\servo\servo\target\debug\build\gleam-596504a3dd4a6e35\out\gl_bindings.rs:953
   6:        0x1439cd05f - gleam::ffi_gl::Gl::GetString
                        at C:\servo\servo\target\debug\build\gleam-596504a3dd4a6e35\out\gl_bindings.rs:2583
   7:        0x1439c37c6 - gleam::gl::{{impl}}::get_string
                        at C:\servo\servo\.cargo\registry\src\github.com-1ecc6299db9ec823\gleam-0.4.4\src\gl_fns.rs:1149
   8:        0x1429d284d - glutin_app::window::Window::new
                        at C:\servo\servo\ports\glutin\window.rs:297
   9:        0x142a19143 - glutin_app::create_window
                        at C:\servo\servo\ports\glutin\lib.rs:50
  10:        0x13f24a656 - servo::main
                        at C:\servo\servo\ports\servo\main.rs:140
  11:        0x143c85e12 - panic_unwind::__rust_maybe_catch_panic
                        at C:\projects\rust\src\libpanic_unwind\lib.rs:98
  12:        0x143c84b9a - std::rt::lang_start
                        at C:\projects\rust\src\libstd\rt.rs:51
  13:        0x13f24b72c - main
  14:        0x14455fd99 - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  15:         0x77a359cd - BaseThreadInitThunk
Servo exited with return value 101

[jdm]

Servo is not using a version of Webrender that includes https://github.com/servo/webrender/pull/1192 yet. We need another PR like https://github.com/servo/servo/pull/16684 that updates our copy.

[jdm]

And yes, please open a separate issue for output when using -z.

[jdm]

The next nightly should include https://github.com/servo/webrender/pull/1192 since #16652 just merged. It would be worth testing to see if Windows nightly builds still exhibit the problem described here.

[jdm]

Sorry, I forgot that https://github.com/servo/servo/issues/16560 is preventing us from updating the Windows nightlies that are published. Only people who can make local builds will be able to test whether this problem has disappeared.

[CAfromCA]

I just re-synced and confirmed my local copy got #16652, but Servo dies with the same error.

[CAfromCA]

I saw several additional WebRender updates pulled into Servo, so I tried compiling a fresh copy. The issue persists.

[kvark]

Is the error message still the same?

vClipMaskUvBounds;p1 different between shaders.

If you search for this name in the current shaders, it only appears here:

flat varying vec4 vClipMaskUvBounds;

And there is nothing unique or wrong about that. I'd expect a problem elsewhere.

[CAfromCA]

My error is unchanged:

Failed to create window.: OsError("wglCreateContextAttribsARB failed: OS Error -1073274731 (FormatMessageW() returned error 317) (os error -1073274731)") (thread main, at src\libcore\result.rs:859)

My error has always been different than the "vClipMaskUvBounds" error that @NiLSPACE, @2efPer, and @recompileorg reported.

My issue could, be the same root cause as theirs, but at the very least it's presenting differently for me. They all have Broadwell or Skylake chips (late 2014 to late 2015) and I have a much older Sandy Bridge CPU/iGPU (mid-2011).

I don't know if any of them can pull the source and compile to see if the recent WR updates fix their issue. it might help resolve whether this is one issue or several.

[kvark]

Thanks @CAfromCA ! It does appear to me that multiple different issues got mixed here, and it's no longer about the GLSL shader linking, given that wglCreateContextAttribsARB happens way before that point.

[CAfromCA]

In that case, I'll create a new issue for my error and let the people seeing "vClipMaskUvBounds" errors figure out if this one is resolved.

[gaby2300]

Hello, I'm still having this issue with the newest build. Is it going to be fixed any time soon?

[jonathandturner]

Ping @glennw - any idea what the fix for this might be?

[glennw]

For the wglCreateContextAttribsARB error, I wonder if the GPU in question doesn't support OpenGL 3.2? I know that some of the 2011 range Intel GPUs only support 3.1 on Windows, but anything newer than that should be fine (and we plan to support 3.1 in the future anyway).

It would be worth opening up the Intel GPU driver control panel, and pasting the output of the OpenGL version information and any other information available here - that may offer some clues as to what is happening.

[CAfromCA]

Several people who commented on #16771 (and I) all seem to have Sandy Bridge-era Intel HD Graphics 3000 iGPUs. Per Wikipedia, at least, Intel only supports up to OpenGL 3.1 on Windows but supports OpenGL 3.3 on Linux and OS X.

https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Sixth_generation

I wasn't able to find a primary source on Intel's site to confirm this, but I installed "OpenGL Extensions Viewer" (a.k.a. GLview, I guess) and it does show my maximum OpenGL version as 3.1.

For whatever it's worth, the three OpenGL 3.2 features (of the 10 listed) this tool says are unsupported by my machine are:

• Shading language version 1.50
• GL_ARB_geometry_shader4
• GL_ARB_texture_multisample

If there's anything else I can get for you about what these GPUs support/lack, let me know!

[gaby2300]

I think it's my case too. Does this mean I won't be able to run these
nightlies till I get a newer PC? Thanks for your help!

On 19 July 2017 at 16:15, CAfromCA [e-mail] wrote:

Several people who commented on #16771
https://github.com/servo/servo/issues/16771 (and I) all seem to have
Sandy Bridge-era Intel HD Graphics 3000 iGPUs. Per Wikipedia, at least,
Intel only supports up to OpenGL 3.1 on Windows but supports OpenGL 3.3 on
Linux and OS X.

https://en.wikipedia.org/wiki/List_of_Intel_graphics_
processing_units#Sixth_generation

I wasn't able to find a primary source on Intel's site to confirm this,
but I installed "OpenGL Extensions Viewer" (a.k.a. GLview, I guess) and it
does show my maximum OpenGL version as 3.1.

For whatever it's worth, the three OpenGL 3.2 features (of the 10 listed)
this tool says are unsupported by my machine are:

• Shading language version 1.50
• GL_ARB_geometry_shader4
• GL_ARB_texture_multisample

If there's anything else I can get for you about what these GPUs
support/lack, let me know!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/servo/servo/issues/16393#issuecomment-316488467, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACDVaMG0VEiOXX_Pgt_v2pKPmxXWECCzks5sPlXWgaJpZM4M8GHe
.

[CAfromCA]

I missed the "It would be worth opening up the Intel GPU driver control panel..." bit earlier, but I just opened mine and I don't see anything in there about OpenGL support.

I'm either looking in the wrong place, or else that's a newer feature that Intel didn't include in their final (and now 2 year-old) set of Sandy Bridge drivers.

Since that appears to be a bust, here's the report generated by the OpenGL Extensions Viewer.

[jonathandturner]

@gaby2300 @CAfromCA - unfortunately this is a limitation of the current system. We do plan to add support for that hardware, but to do so will be to move our OpenGL work over to ANGLE(https://github.com/google/angle). This work is still a ways out.

[gaby2300]

@jonathandturner Many thanks for letting me know about this! You saved me from trying and failing again and again! By still a ways out do you mean it will take a long time?

[jonathandturner]

@gaby2300 - I can only speculate on when the support will be available, unfortunately.

[CAfromCA]

@jonathandturner Given the cause seems to have been identified (Sandy Bridge doesn't support OpenGL 3.2 on Windows) and it sounds like there is a clear fix identified and planned (migrate Windows to use ANGLE), is it safe for me to update and close #16771?

[gaby2300]

@jonathandturner I understand! Thanks anyway!