GNOME Bugzilla – Bug 775045
gtkglsink: re parenting the video widget into a different toplevel does not work
Last modified: 2018-11-03 15:14:53 UTC
Created attachment 340711 [details] Simple test case Reparenting the video widget from gtkglsink to a different toplevel does not work because the GdkGLContext is different and GtkGstGLWidget uses the old one. This is needed to implement fullscreen for example. Ideally GtkGstGLWidget should get the context in the realize event and free it on unrealize if possible. Attached a simple test case that toggles fullscreen mode on key release
Created attachment 340760 [details] Test case using videotestsrc
Created attachment 340764 [details] [review] Small patch to use g_clear_pointer() macros
Created attachment 340765 [details] [review] WIP try to initialize GL context on realize event After the second realize I get a bunch of (a.out:13651): Gtk-WARNING **: fb setup not supported bacause glCheckFramebufferStatusEXT() in gtk_gl_area_draw() does not return GL_FRAMEBUFFER_COMPLETE_EXT
Created attachment 371869 [details] [review] WIP: initialize GL context on realize event This patch makes going back to windowed mode work
Review of attachment 371869 [details] [review]: The other part: changing the display/context used by the pipeline requires some thinking/design work as the GstContext machinery does not have support for that. The easiest thing I can come up with is to add a 'resource-destroyed'-like signal on both GstGLDisplay and GstGLContext where on emission each user attempts to retrieve a new GstGLDisplay/GstGLContext. ::: ext/gtk/gtkgstglwidget.c @@ +377,3 @@ + if (!priv->other_context) { + GTK_GST_BASE_WIDGET_UNLOCK (gst_widget); + gst_gtk_invoke_on_main ((GThreadFunc) _get_gl_context, gst_widget); Aren't we always called on the main thread already from GtkWidget? @@ +388,3 @@ + + if (priv->context) + retval = gst_gl_display_add_context (priv->display, priv->context); retval isn't declared or used.
(In reply to Matthew Waters (ystreet00) from comment #5) > Review of attachment 371869 [details] [review] [review]: > > The other part: changing the display/context used by the pipeline requires > some thinking/design work as the GstContext machinery does not have support > for that. > > The easiest thing I can come up with is to add a 'resource-destroyed'-like > signal on both GstGLDisplay and GstGLContext where on emission each user > attempts to retrieve a new GstGLDisplay/GstGLContext. I havent looked at the code at all, but from a quick look at the API I would add 'context-removed' signal and gst_gl_display_remove_context () function to GstGLDisplay. For GstGLContext maybe we can get away with a weak reference or we can add GtkWidget::destroy like signal if needed > ::: ext/gtk/gtkgstglwidget.c > @@ +377,3 @@ > + if (!priv->other_context) { > + GTK_GST_BASE_WIDGET_UNLOCK (gst_widget); > + gst_gtk_invoke_on_main ((GThreadFunc) _get_gl_context, gst_widget); > > Aren't we always called on the main thread already from GtkWidget? yeah! copy/paste left over > @@ +388,3 @@ > + > + if (priv->context) > + retval = gst_gl_display_add_context (priv->display, priv->context); > > retval isn't declared or used. Ops, I tried to remove all the debug things but missed that one
Created attachment 371913 [details] [review] WIP: initialize GL context in create_context method GtkGLArea create-context signal looks like a good place to initialize all the GL wrappers objects. This still does not fix all issues, but I just want to post it here to get some feedback
Created attachment 371914 [details] [review] WIP: GstGLDisplay add context-removed signal and remove_context()
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/330.