WebGL does not work in Windows

[jdm]

Simplest possible testcase: http://web.cse.ohio-state.edu/~shen.94/5542/Site/WebGL_files/code00.html

[jdm]

From a non-UWP debug build on the same machine (WGL codepath instead of EGL):

[2019-07-04T19:53:16Z WARN  canvas::webgl_thread] Couldn't create shared GL context (Error creating WGL context: WGL::MakeCurrent failed in shared context), using slow readback context instead.
[2019-07-04T19:53:16Z WARN  servo] Panic hook called.
called `Option::unwrap()` on a `None` value (thread WebGLThread, at src\libcore\option.rs:347)
stack backtrace:
   0: backtrace::backtrace::trace_unsynchronized<closure> (0x7ff614d16cf2)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.26\src\backtrace\mod.rs:66
   1: backtrace::backtrace::trace<closure> (0x7ff614d16c20)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.26\src\backtrace\mod.rs:53
   2: backtrace::capture::Backtrace::create (0x7ff6128b8d08)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.26\src\capture.rs:163
   3: backtrace::capture::Backtrace::new (0x7ff6128b8c19)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.26\src\capture.rs:126
   4: servo::main::{{closure}} (0x7ff611883237)
             at C:\Users\image\servo\ports\glutin\main2.rs:116
   5: std::panicking::rust_panic_with_hook (0x7ff612c00135)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libstd\panicking.rs:479
   6: std::panicking::continue_panic_fmt (0x7ff612bffc44)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libstd\panicking.rs:382
   7: std::panicking::rust_begin_panic (0x7ff612bffb29)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libstd\panicking.rs:309
   8: core::panicking::panic_fmt (0x7ff612c133dc)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libcore\panicking.rs:85
   9: core::panicking::panic (0x7ff612c1331e)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libcore\panicking.rs:49
  10: core::option::Option<mut winit::platform::platform::events_loop::ThreadLocalData*>::unwrap<mut winit::platform::platform::events_loop::ThreadLocalData*> (0x7ff612776399)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libcore\macros.rs:12
  11: winit::platform::platform::events_loop::callback_inner::{{closure}} (0x7ff6127d5f3b)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.19.1\src\platform\windows\events_loop.rs:508
  12: std::thread::local::LocalKey<core::cell::RefCell<core::option::Option<winit::platform::platform::events_loop::ThreadLocalData>>>::try_with<core::cell::RefCell<core::option::Option<winit::platform::platform::events_loop::ThreadLocalData>>,closure,()> (0x7ff614d7a1be)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\thread\local.rs:299
  13: std::thread::local::LocalKey<core::cell::RefCell<core::option::Option<winit::platform::platform::events_loop::ThreadLocalData>>>::with<core::cell::RefCell<core::option::Option<winit::platform::platform::events_loop::ThreadLocalData>>,closure,()> (0x7ff614d79fad)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\thread\local.rs:245
  14: winit::platform::platform::events_loop::callback_inner (0x7ff6127d326b)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.19.1\src\platform\windows\events_loop.rs:505
  15: winit::platform::platform::events_loop::callback::{{closure}} (0x7ff6127d2e36)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.19.1\src\platform\windows\events_loop.rs:484
  16: std::panicking::try::do_call<closure,isize> (0x7ff612795da4)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\panicking.rs:294
  17: panic_unwind::__rust_maybe_catch_panic (0x7ff612c0c9a2)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libpanic_unwind\lib.rs:82
  18: std::panicking::try<isize,closure> (0x7ff61279575d)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\panicking.rs:273
  19: std::panic::catch_unwind<closure,isize> (0x7ff612795699)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\panic.rs:388
  20: winit::platform::platform::events_loop::run_catch_panic<closure,isize> (0x7ff6127d2676)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.19.1\src\platform\windows\events_loop.rs:455
  21: winit::platform::platform::events_loop::callback (0x7ff6127d2dd1)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.19.1\src\platform\windows\events_loop.rs:484
  22: CallWindowProcW (0x7ffccf3f681d)
  23: DispatchMessageW (0x7ffccf3f63ec)
  24: UnionRect (0x7ffccf404e82)
  25: KiUserCallbackDispatcher (0x7ffcd0f1fdb4)
  26: NtUserCreateWindowEx (0x7ffcce601f24)
  27: CreateWindowExW (0x7ffccf3e8001)
  28: CreateWindowExW (0x7ffccf3e7bf4)
  29: CreateWindowExW (0x7ffccf3e7a32)
  30: offscreen_gl_context::platform::with_wgl::utils::create_hidden_window (0x7ff6181b4563)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\offscreen_gl_context-0.22.3\src\platform\with_wgl\utils.rs:184
  31: offscreen_gl_context::platform::with_wgl::utils::create_offscreen (0x7ff6181b2ac3)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\offscreen_gl_context-0.22.3\src\platform\with_wgl\utils.rs:41
  32: offscreen_gl_context::platform::with_wgl::native_gl_context::{{impl}}::create_shared_with_dispatcher (0x7ff615aec81d)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\offscreen_gl_context-0.22.3\src\platform\with_wgl\native_gl_context.rs:174
  33: offscreen_gl_context::gl_context::GLContext<offscreen_gl_context::platform::with_wgl::native_gl_context::NativeGLContext>::create_shared_with_dispatcher<offscreen_gl_context::platform::with_wgl::native_gl_context::NativeGLContext> (0x7ff615aff1bd)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\offscreen_gl_context-0.22.3\src\gl_context.rs:46
  34: offscreen_gl_context::gl_context::GLContext<offscreen_gl_context::platform::with_wgl::native_gl_context::NativeGLContext>::new_shared_with_dispatcher<offscreen_gl_context::platform::with_wgl::native_gl_context::NativeGLContext> (0x7ff615afde4b)
             at C:\Users\image\.cargo\registry\src\github.com-1ecc6299db9ec823\offscreen_gl_context-0.22.3\src\gl_context.rs:110
  35: canvas::gl_context::GLContextFactory::new_context (0x7ff612e6ae0e)
             at C:\Users\image\servo\components\canvas\gl_context.rs:98
  36: canvas::webgl_thread::{{impl}}::create_webgl_context::{{closure}}<canvas::webgl_mode::inprocess::WebVRRenderWrapper> (0x7ff614cd0d28)
             at C:\Users\image\servo\components\canvas\webgl_thread.rs:285
  37: core::result::Result<(canvas::gl_context::GLContextWrapper, canvas_traits::webgl::WebGLContextShareMode), str*>::or_else<(canvas::gl_context::GLContextWrapper, canvas_traits::webgl::WebGLContextShareMode),str*,str*,closure> (0x7ff615b2788c)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libcore\result.rs:709
  38: canvas::webgl_thread::WebGLThread<canvas::webgl_mode::inprocess::WebVRRenderWrapper>::create_webgl_context<canvas::webgl_mode::inprocess::WebVRRenderWrapper> (0x7ff614cd0568)
             at C:\Users\image\servo\components\canvas\webgl_thread.rs:276
  39: canvas::webgl_thread::WebGLThread<canvas::webgl_mode::inprocess::WebVRRenderWrapper>::handle_msg<canvas::webgl_mode::inprocess::WebVRRenderWrapper> (0x7ff614cceef8)
             at C:\Users\image\servo\components\canvas\webgl_thread.rs:121
  40: canvas::webgl_thread::{{impl}}::start::{{closure}}<canvas::webgl_mode::inprocess::WebVRRenderWrapper> (0x7ff614cceb06)
             at C:\Users\image\servo\components\canvas\webgl_thread.rs:104
  41: std::sys_common::backtrace::__rust_begin_short_backtrace<closure,()> (0x7ff61908cf86)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\sys_common\backtrace.rs:77
  42: std::thread::{{impl}}::spawn_unchecked::{{closure}}::{{closure}}<closure,()> (0x7ff6181403e6)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\thread\mod.rs:470
  43: std::panic::{{impl}}::call_once<(),closure> (0x7ff61908ce96)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\panic.rs:309
  44: std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure>,()> (0x7ff619651cec)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\panicking.rs:294
  45: panic_unwind::__rust_maybe_catch_panic (0x7ff612c0c9a2)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libpanic_unwind\lib.rs:82
  46: std::panicking::try<(),std::panic::AssertUnwindSafe<closure>> (0x7ff619651aaf)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\panicking.rs:273
  47: std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure>,()> (0x7ff61908ced6)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\panic.rs:388
  48: std::thread::{{impl}}::spawn_unchecked::{{closure}}<closure,()> (0x7ff6181401cc)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libstd\thread\mod.rs:469
  49: core::ops::function::FnOnce::call_once<closure,()> (0x7ff614cbc103)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\libcore\ops\function.rs:231
  50: alloc::boxed::{{impl}}::call_once<(),FnOnce<()>> (0x7ff612bea387)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\src\liballoc\boxed.rs:746
  51: std::sys::windows::thread::{{impl}}::new::thread_start (0x7ff612c0afa6)
             at /rustc/04a3dd8a872633ca1e4c217d11f741cc35cb19a5\/src\libstd\sys\windows\thread.rs:47
  52: BaseThreadInitThunk (0x7ffccf597bd4)
  53: RtlUserThreadStart (0x7ffcd0eece71)

[jdm]

Unfortunately #23656 means that we can't test the EGL codepath in desktop builds right now.

[jdm]

However in a June 10 nightly that supported running with --angle the testcase still did not successfully create a webgl canvas.

[jdm]

With #23656 fixed and building with --features no_wgl to ensure the EGL codepath is taken, webgl context initialization still fails.

[jdm]

I successfully got a desktop build to display a webgl canvas with the following formula:

• fix #23656 to generate a libGLESv2.dll
• copy libGLESv2.dll to the servo build directory along with libEGL.dll
• build with --features no_wgl
• modify https://github.com/servo/rust-offscreen-rendering-context/blob/3e650415caf5ee6a2db18210b1ddafb7f258c39e/src/platform/with_egl/native_gl_context.rs#L15 t load libGLESv2.dll instead
• pass GlType::Gles when creating the offscreen context in

  servo/components/canvas/gl_context.rs

  Line 67 in 76d3272

  gl::GlType::default(),

• run with --angle

[jdm]

With the previous formula, this simple example fails: http://mdn.github.io/webgl-examples/tutorial/sample4/

WARN: resolveCompile(441):
WARNING: 0:1: 'GL_ARB_gpu_shader5' : extension is not supported
ERROR: 0:2: '' : No precision specified for (float)

ALERT: Unable to initialize the shader program: No compiled fragment shader when at least one graphics shader is attached.

[jdm]

Using the previous formula and a --uwp build, I successfully loaded http://web.cse.ohio-state.edu/~shen.94/5542/Site/WebGL_files/code00.html in the UWP build. http://mdn.github.io/webgl-examples/tutorial/sample4/ does not display anything, but I see this output:

RUST: WARN - Error enabling GL point sprites: 1280
RUST: WARN - Error enabling GL program point size: 1280
RUST: ERROR - Error at https://mdn.github.io/webgl-examples/tutorial/sample4/webgl-demo.js:57:26 Value is not an object.

[jdm]

When I hardcode is_gles() from canvas_traits/webgl.rs to true, the warnings go away. When I make the vslogger print out all info messages, an alert from the page appears:

RUST: INFO - Alert: Unable to initialize the shader program: 

This explains the JS error, which comes from gl.getAttribLocation(shaderProgram, 'aVertexPosition'),. It's curious that gl.getProgramInfoLog(shaderProgram) returns the empty string, however.

[jdm]

Adding code to the webgl thread that checks the status of shader compilation and prints out the shader info log if it fails yields the following in the UWP app:

RUST: WARN - Shader compile error: WARNING: 0:1: 'GL_ARB_gpu_shader5' : extension is not supported
ERROR: 0:2: '' : No precision specified for (float) 

[jdm]

Switching from GLSL output to ESSL makes the shaders compile. We now hit an assertion inside the D3D11 state manager: https://github.com/servo/mozangle/blob/2198a1354f895b08412c2e817366dc025bd1083a/gfx/angle/checkout/src/libANGLE/renderer/d3d/d3d11/StateManager11.cpp#L2227

[jdm]

More importantly: we crash when executing https://github.com/servo/mozangle/blob/2198a1354f895b08412c2e817366dc025bd1083a/gfx/angle/checkout/src/libANGLE/renderer/d3d/d3d11/Framebuffer11.cpp#L72 because we use a framebuffer object whose state comes from a framebuffer that was deleted as part of make_not_current (

servo/ports/glutin/headed_window.rs

Line 518 in 988e38f

self.gl_context.borrow_mut().make_not_current();

).

[jdm]

Curiously, forcing readback mode does not affect the crash caused by sharing framebuffer state.

[jdm]

If I comment out the make_not_current call then that crash is replaced by a different one.

[jdm]

The crashes appear to come from the fact that ANGLE has a single underlying Direct3D resource that is used for all contexts, so it does not like to have multiple contexts distributed across threads operating simultaneously (microsoft/angle#61, microsoft/angle#65). When I merged the webgl thread with the main thread, I successfully displayed an animating webgl canvas in the desktop app.

[jdm]

I got animating webgl content displaying in the UWP app as well by adding a thread that relays all of the webgl messages from the script thread to the "webgl thread" (ie. main thread) and kicks the event loop alive so the app doesn't deadlock: https://www.joshmatthews.net/hlservo.mp4

[jdm]

I think in the short term it would be best to make it possible to run the webgl thread on the main thread, and longer term we could investigate following microsoft/angle#65 and creating a second d3d device and sharing textures between them to retain our separate webgl thread. I would rather start from a working implementation as soon as possible than spend time potentially investigating a fruitless path.