Make the "gl-context" property of the GstGLSink readable as well so that
we can query whether the GstGLContext sharing really succeeded. If it
did, then we proceed to playback our video using the glimagesink as we
did before. If it didn't, throw out the GtkGstSink we were creating, and
re-create the GtkGstSink without the "gl-context" property, meaning that
we won't be using the glimagesink in this case.
Add support to look for and use the EGL context in Windows if it was activated
instead of desktop OpenGL.
GstGL may have been built with or without EGL/libANGLE support, so if it were,
check in GstGL whether we have gst_gl_display_new_with_type() to create a
GstGLDisplay that is of the GST_GL_WINDOW_WIN32 type when we are using
Desktop OpenGL (WGL), otherwise we show messages indicating that envvars
need to be set to initialize GstGL properly.
Due to a bug in GstGL, the GstGLContext can only be set up successfully
if one of the following is true:
* An OpenGL 3.x or later emulator, such as Mesa is used (for WGL)
* The latest GstGL master is being used, at the time of writing (for
WGL)
* GTK, libepoxy and GstGL are all built only with WGL support (for WGL)
* EGL is being used in GTK at runtime
Special thanks to Matthew Waters for the help during the process.
Add support to share the WGL context in GDK with the WGL context in GStreamer,
so that we can also use OpenGL in the gstreamer media backend to playback
videos. For now OpenGL/ES is not supported for this under Windows.
The process of setting this up in Windows is a little bit more involved, as:
* The OpenGL support in GstGL requires a GL 4.1 Core context, but we may just
get the GL version from wglCreateContextAttribsARB() that we pass into the
attributes, which is 3.2 by default. So, try to ask for a 4.1 Core context
first if we are asking for anything less.
* There is only one GstDisplay available for Windows, so we just use
gst_gl_display_new().
* We must explicitly tell libepoxy that we are using wglMakeCurrent() outside
of libepoxy that is being used in GdkGL, otherwise we would end up crashing
as the GL/WGL function pointers would become invalid.
* We must also deactivate temporarily the underlying WGL context that was made
current by gdk_gl_context_make_current() so that when
gst_gl_display_create_context() calls wglShareLists(), we won't get bitten
by error 0xaa (resource busy), as some drivers don't handle this well when
the GL context is current in another thread.
For the last two points we make use of macros defined by the platforms that the
build is done for to help us carry out the necessary tasks as needed.
Thanks to Matthew Waters for the info on integrating GstGL and windowing
toolkits on Windows.
Visual Studio 2013's linker does not suport `/WHOLEARCHIVE:`, so just
explicitly extract the objects from the static libraries that will
form the final GTK DLL.
We want to find focusable children, so we need to look at
the focusable property, not at can-focus. This is a change
from GTK 3, where can-focus was the correct property to
look at.
The intention of the code is to find a focusable ancestor,
so it needs to look at the focusable property, not at
can-focus. This is a change from GTK 3, where can-focus
was the correct property to look at.
Fixes: #3965
Check that we are indeed running inside an Xorg server before enabling
the workaround.
XWayland or other nested X servers deadlock when that workaround is
applied.
