WIP: GL support for MacOS

[ceyusa]

This MR is a continuation of #284

• Rebased to current master
• Instead of using a modified glutin crate, it uses the native cgl crate
• Refactored the GstGL bindings for MacOS mimicking the crate split for sys and api, doing the linking only in sys

[ceyusa]

The player test fails because with GL Error 0x506, that is GL_INVALID_FRAMEBUFFER_OPERATION: Given when doing anything that would attempt to read from or write/render to a framebuffer that is not complete.

The error is produced when WR tries to clear its rendering target:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `1286`,
 right: `0`', /Users/vjaquez/.cargo/registry/src/github.com-1ecc6299db9ec823/gleam-0.6.8/src/gl.rs:93:1
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /Users/vsts/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /Users/vsts/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:339
   9: <gleam::gl::ErrorCheckingGl as gleam::gl::Gl>::clear
             at /Users/vjaquez/.cargo/registry/src/github.com-1ecc6299db9ec823/gleam-0.6.8/src/gl.rs:86
  10: webrender::device::gl::Device::clear_target
             at /Users/vjaquez/.cargo/registry/src/github.com-1ecc6299db9ec823/webrender-0.60.0/src/device/gl.rs:2645
  11: webrender::renderer::Renderer::render_impl::{{closure}}
             at /Users/vjaquez/.cargo/registry/src/github.com-1ecc6299db9ec823/webrender-0.60.0/src/renderer.rs:2593
  12: webrender::profiler::TimeProfileCounter::profile
             at /Users/vjaquez/.cargo/registry/src/github.com-1ecc6299db9ec823/webrender-0.60.0/src/profiler.rs:253
  13: webrender::renderer::Renderer::render_impl
             at /Users/vjaquez/.cargo/registry/src/github.com-1ecc6299db9ec823/webrender-0.60.0/src/renderer.rs:2563
  14: webrender::renderer::Renderer::render
             at /Users/vjaquez/.cargo/registry/src/github.com-1ecc6299db9ec823/webrender-0.60.0/src/renderer.rs:2496
  15: player::app::main_loop
             at examples/player/app.rs:463
  16: core::ops::function::FnOnce::call_once
             at /rustc/60960a260f7b5c695fd0717311d72ce62dd4eb43/src/libcore/ops/function.rs:235
  17: core::result::Result<T,E>::and_then
             at /rustc/60960a260f7b5c695fd0717311d72ce62dd4eb43/src/libcore/result.rs:691
  18: player::main
             at examples/player/main.rs:79
  19: std::rt::lang_start::{{closure}}
             at /rustc/60960a260f7b5c695fd0717311d72ce62dd4eb43/src/libstd/rt.rs:64
  20: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:49
  21: std::panicking::try::do_call
             at src/libstd/panicking.rs:296
  22: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  23: std::panicking::try
             at src/libstd/panicking.rs:275
  24: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  25: std::rt::lang_start_internal
             at src/libstd/rt.rs:48
  26: std::rt::lang_start
             at /rustc/60960a260f7b5c695fd0717311d72ce62dd4eb43/src/libstd/rt.rs:64
  27: player::main

Which is the same error previous to the clean up, rebase and refactor.

Following the GStreamer log, it seems that the render target created by the internal GStreamer GL context is made current (!!!) when WR wants to clear the current target, which is the GStreamer one, exposing that error.

I suspect this is a GStreamer error on its MacOS bits. Also, as far as I known, nobody has tried the texture uploading to an external application on Mac before.

[ceyusa]

I've filed an issue for gst-plugins-base: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/671

[ceyusa]

I tried to copy cat what offscreen-gl-context does, creating a new shared context, but I hit with the same issue as servo/surfman#82

If I create a new context, the original problem arise: gstreamer's shared context draws first and deactivate the context while webrender tries to use it.

[jdm]

Yes, that makes sense to me. We're changing our WebGL model away from shared contexts to using shared surfaces instead (based on https://github.com/pcwalton/surfman) in order to avoid that problem on macOS. It's not clear to me if that's a solution for supporting GL in gstreamer on macOS, though, since gstreamer is based on shared contexts.

[bors-servo]

☔ The latest upstream changes (presumably #319) made this pull request unmergeable. Please resolve the merge conflicts.