[Bug 704808] Split GstGLDisplay into that and GstGLContext

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=704808
  GStreamer | gst-plugins-gl | git

--- Comment #3 from Matthew Waters <ystreet00 at gmail.com> 2013-08-15 12:23:23 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > have to check whether vfuncs are per context or not
> 
> They are not, but they depend on the GL version used. GLES vs. desktop GL at
> least. However we can't reliable load different ones in the same process
> anyway.

Technically calling wglGetProcAddress with different contexts can return
different values however I don't think that it occurs in practice.  Cogl does
them per context.  Actually with mesa, you get the same function regardless of
GL vs GLES however I don't think that mesa allows both GL and GLES to be used
at the same time (not tested).

> > GstGLContext - represents a GL context.  As such is platform specific (GLX,
> > EGL, WGL, etc).  Holds a reference to a single GstGLWindow.
> > GstGLWindow - represents a window/surface that we are rendering to/with. 
> > Eventually will be split into 2 categories, offscreen and onscreen.
> 
> Can't we have a GL context without a window? E.g. the filters don't really
> require a window (offscreen or onscreen)

Some platforms allow it (depending on GL Version or extension), some don't.  On
Win32 the only way you can get a HDC is from a window.  GLX only allows it with
GL 3.0+.  EGL has EGL_KHR_surfaceless_context.  Dunno about Cocoa.  Besides, I
put the display connection stuff into GstGLWindow :) it seems useless to create
a seperate object for one variable :).

> Otherwise sounds like a good plan :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.