This allows us to remove races when setting the wl_queue on wayland
objects with wl_proxy_set_queue() as each created object is created with
the queue already set.
We can also move all our initilization code into the window as we
can retrieve all wayland objects from each window instance. This
removes a possible race when integrating with external API's as we would
always attempt to immediately retrieve a small set of wayland objects.
That is no longer the case with the objects from each window instance.
It seems that eglCreatePlatformWindowSurfaceEXT is failing (with
EGL_BAD_ALLOC) because it thinks an EGL surface has already been created
for the wl_egl_window. The reason is that the "driver_private" field of
the wl_egl_window is getting clobbered by the function
wl_proxy_set_queue().
Since a wl_egl_window is not a wl_proxy, it shouldn't be passed to
wl_proxy_set_queue(). It just wraps a wl_surface (which is a wl_proxy).
And it looks like the queue for that surface is getting set earlier on
in the function anyway.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/621#note_184582
As part of commit 808e7127, we prefixed the `GstWlWindow`'s `shell`
field with wl_, to differentiate it from the other types of shells a
Wayland compositor might support. However, this is apparently a struct
that we expose to our users, so changing it means we have an API break.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/592
The glimagesink wayland backend lacks the implementation of
gst_gl_window_wayland_egl_set_preferred_size. Because of this, glimagesink windows on
wayland are created with a fixed window size of 320x240.
[Matthew Waters]: gst-indent sources
https://bugzilla.gnome.org/show_bug.cgi?id=789384
No-one's using/depending on it (it would have criticalled and not worked)
and it's causing more problems than it's solving. Store the GMainContext
in the public struct instead for subclasses to optionally use instead of
relying on the push/pop state to be correct.
https://bugzilla.gnome.org/show_bug.cgi?id=775970
- glimagesink needs to be able to resize the viewport on aspect ratio
changes resulting from either caps changes or 3d output mode changes.
- Performing a glViewport outside the GstGLWindow::resize callback
will not have the winsys' stack of viewports required to correctly
place the output frame.
Provide a function to request a resize on the next draw event from the
winsys.
Also track size changes inside the base GstGLWindow class rather
than in each subclass.
https://bugzilla.gnome.org/show_bug.cgi?id=755111
Simple implementation split from GstGLWindowWayland
Can now have multiple glimagesink elements all displaying output
linked via GL or otherwise (barring GL platform limitations).
The intel driver is racy and can crash setting up the two glimagesink contexts.
e.g.
videotestsrc ! tee name=t ! queue ! glupload ! glimagesinkelement
t. ! queue ! gleffects_blur ! glimagesinkelement
videotestsrc ! glupload ! glfiltercube ! tee name=t ! queue ! glimagesinkelement
t. ! queue ! gleffects_blur ! glimagesinkelement
Depending on the platform, it was only ever implemented to 1) set a
default surface size, 2) resize based on the video frame or 3) nothing.
Instead, provide a set_preferred_size () that elements/applications
can use to request a certain size which may be ignored for
videooverlay/other cases.
We cannot use _finalize as this will be called before GstGLWindow's
_finalize. This causes us to try and perform operations with the
wayland server when the connection has been severed.
