[Bug 752743] gl: add support for egl+x11+swrast on osx

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sat Jul 25 01:44:30 PDT 2015


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

--- Comment #21 from Matthew Waters <ystreet00 at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #19)
> (side note: about a _new implementation that can fail, if you ever want to
> implement one, implement the interface GInitable, it will make this more
> binding friendly)

However that pulls in GIO for one interface which isn't great.

(In reply to Julien Isorce from comment #20)
> If I remove the "&& _get_default_gl_platform() =="
> then when using cgl it fails with:
> ERROR: from element
> /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
> glGetString not defined or returned invalid value
> 
> Maybe it would be better to have gstglcontext in this function to get its
> platform.
> It would require to change api of gst_gl_context_default_get_proc_address to
> pass the gstglcontext pointer or its platform. Not sure how exactly yet
> because of gst_gl_context_get_proc_address_with_platform deps.

Are there two competing opengl libraries installed that you're trying to select
between depending on the GL platform in use?  I don't think that's going to be
easy to solve generically without resorting to hacks that will only work in
specific configurations.  I'd say leave this to the compile time choice of the
opengl/gles2 library to use (already exists).  Or find some nice way to bake
this into the gl platform specific context implementations rather than
overloading the default implementation.

By the time you're in the default_get_proc_address, the context specific
GstGLContext get_proc_address() has potentially been run (most start with the
default implementation first though).

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


More information about the gstreamer-bugs mailing list