[Bug 750310] New: Ideas around GstGLContextGPUProcess

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=750310

            Bug ID: 750310
           Summary: Ideas around GstGLContextGPUProcess
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: julien.isorce at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Recently I introduced GstGLContextGPUProcess
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=b377112ee38912d316e77b4e2102041389dc0051

This backend is useful for any application that only provides its own proc_addr
to forward gl calls to a dedicated GPU process.

I agree with Matthew that it should probably stay in the application. Though we
need to figure out how to handle the case in glimagesink (see link above). I
could check if other_context has a window but it is hard to maintain.

Matthew you suggested to handle this through some new signals in GstGLDisplay.
As discussed already that would be great if you can put your detailed ideas
here.

What I basically need is 3 things:

- 1: Tell that other_context the app provides (the GstGLGPUContext) through
GST_MESSAGE_NEEDS_CONTEXT is not a context to share resources with but it is a
replacement.

- 2: The app is connected to glimagesink's "client-draw" signal.
gst_gl_window_draw should take the glimagesink's _draw_cb in parameter (instead
of installing a cb).

(- 3: The gstgldisplay is unique in my case and do not rely on any platform
since I do not go through all gst_gl_context creations. )

1 and 2 would avoid the special case in glimagesink I mentioned above.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.