After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704807 - gl: Simplify windowing logic
gl: Simplify windowing logic
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-24 12:45 UTC by Sebastian Dröge (slomo)
Modified: 2018-05-05 21:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2013-07-24 12:45:08 UTC
Just create offscreen surfaces if no window is required, don't have the complicated re-parenting logic (that only works on some platforms) for the windows there. And require GstVideoOverlay to be used before going to READY.
Comment 1 Julien Isorce 2014-01-06 22:27:35 UTC
It's already implemented on egl. See eglCreatePbufferSurface (or EGL_KHR_surfaceless_context) in gstglcontext_egl.c.

So we need to do the same thing on glx, wgl and cocoa.

Well almost everything on egl except the fact that we could accept a NULL window. As done here: https://bug704809.bugzilla-attachments.gnome.org/attachment.cgi?id=265481
Comment 2 Philippe Normand 2015-03-16 18:14:44 UTC
The code is there but is not triggered, I think. At least for the dispmanx/egl backend.

From what I can see here, in gstglwindow_dispmanx_egl.c a native window is created and get_window_handle() returns a non-null result. So in gstglcontext_egl  and EGLSurface is created for the handle and the other branch (surfaceless context) is not triggered.

The use-case I have in mind is to use glimagesink::client-draw within WebKit. For that I don't think I need the gstglwindow_dispmanx to create a native window because it's handled by WebKit instead.

I'm not sure how it's all supposed to work but shouldn't the native window support be optional, in the Dispmanx and perhaps Android/EGL cases?
Comment 3 Julien Isorce 2015-03-17 15:37:21 UTC
Philippe there are 2 options:

1: implement gst_gl_window_dispmanx_show because currently it is visible even if glimagesink does not call gst_gl_window_show.

2: Try with GST_GL_WINDOW=none ?  (none or whatever name different than dispmanx, x11, cocoa, wayland, win32, eagl)
It will use gst_gl_dummy_window_new internally. But not sure if it will work if the contexts shared ressources because the need of having same display.

You make me realize that if "egl && glimagesink->other_context && "client-draw" connected", then glimagesink can use the dummy window instead of creating an unvisible one. 

(We can apply same logic for other GST_GL_PLATFORM when support will be there)
Comment 4 Philippe Normand 2015-03-24 15:24:55 UTC
My dispmanx issues were fixed in bug 746632 :)
Comment 5 Julien Isorce 2015-03-24 16:54:00 UTC
So here we need to do same as http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/egl/gstglcontext_egl.c#n386

Adding support for glXCreatePbuffer would be great.
Comment 6 Matthew Waters (ystreet00) 2018-05-05 21:09:18 UTC
Not going to be implemented as adding glimagesink to an already running pipeline would break very badly then.