Since we are making GdkGLContext call the core wgl*() functions directly
instead of via libepoxy, drop the workarounds that we needed for notifying
libepoxy that wglMakeCurrent() outside of GDK/GTK was called.
This way, we clean up the code, and as a result, we can use the GstGL
APIs like the other platforms to query what GL api that is to be used.
For ensuring that things work between different threads, we now call
gdk_gl_context_clear_current() in place of calling wglMakeCurrent(xxx,
NULL), so that we make sure that there is no current GL context on a
thread outside of GstGL's thread, which Windows does not like.
The current definitions of the g_io_module_*() symbols do not build on
Visual Studio when building against GLib earlier than 2.75.0 due to the
way how these symbols are decorated in the GLib headers, as Visual Studio
does not allow symbols that were previously marked with 'extern' (or so)
to be marked with anything that is symantically different later.
As a result, if we are using Visual Studio and glib-2.74.x or earlier,
override _GLIB_EXTERN as appropriate in the modules/media sources before
including the GIO headers. This sadly, means that we need a
configure-time check as it would have been too late if we checked the
GLib version using G_VERSION_CHECK macro, as the GIO headers would have
been included already.
There are similar items in the print backends, but we will not attempt
to update these files as they are not meant to be built for Windows.
It does not make sense to sync and wait in the
same context, that is just a no-op. The intention
of this code clearly was to sync in the gst
context, and wait in the gdk one.
That also matches what the gtk sink implementation
in gstreamer does.
This reverts commit acd9c12667.
This commit breaks the build with GLib main on all platforms,
and defining _GLIB_EXTERN arguably invades the GLib namespace.
A different fix for msvc will have to be found.
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
This seems to be a problem since:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3565
To demo the problem, the video demo in gtk4-demo is currently set to
autoplay, but it doesn't autoplay on load as expected because the
"prepared" notification doesn't fire until the user explicitly presses
play.
Similarly if the demo is tweaked to disable autoplay then on loading a
video (or an audio-only ogg) the duration is not known or shown until
the user presses play.
In LibreOffice we want to know what the size of the video is to position
it before the user can interact with it to set it to play. We can
workaround this to some degree by listening to "invalidate-size" on the
GtkMediaStream object which updates for videos, but that doesn't wor
for audio-only streams.
So restore listening to media-info-updated but ignore -1 (which I see
for audio-only where I get -1 and then a useful value) and 0 of the
original report.
see also:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3550GNOME/gtk!4513
If we have GStreamer on macOS we likely have support for CGL to get an
OpenGL context we can use. This provides the missing pieces to get
accelerated video playback in gtk4-widget-factory working.
When loading .mp3 files the duration is initially unknown. Before this
change it was reported as a large integer (since GST_CLOCK_TIME_NONE is
-1). Now it's correctly reported as 0.
Also rename gtk_media_stream_ended to
gtk_media_stream_set_ended, to avoid naming
collision with GtkMediaStream:ended.
The existing entry points still exist, deprecated
and marked as non-introspectable.
Update all internal uses.
Fixes: #4023
Some bindings can't handle the coexistence of
GtkMediaStream:prepared and gtk_media_stream_prepared.
Help them out by renaming the function to
gtk_media_stream_set_prepared, and rename
gtk_media_stream_unprepared as well, to match.
The existing entry points still exist, deprecated.
Update all internal uses.
Fixes: #4023
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.
As long as we can create a GL context, pass one to
gstreamer. This at least gets us GL textures with
the ngl renderer, the previous code was arbitrarily
refusing that.
GModule requires the .so file extension on macOS for historic reasons.
However Meson defaults to .dylib for modules, so we need to override
it to get the correct extension.
Fixes#3645.
Visual Studio 2013 is just shy of being sufficiently C99-compliant to
build GTK master, as it did not support snprintf() in its CRT
implementation.
Use g_snprintf() to cover for this.
...for at least WGL, since we are not allowed to use wglMakeCurrent(),
which is eventually called by gdk_gl_context_make_current() to share WGL
contexts across different threads, which will cause a crash.
This means, we cannot enable WGL in the gstreamer media backend on
Windows.
