It's possible that the sink element will be freed before the widget is
destroyed. When the widget was eventually destroyed, it was attempting to
access member variables of the freed sink struct which resulted in undefined
behaviour.
Fix by disconnecting our signal on finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=762098
CPU waits are more expensive and are only required if the CPU is ever going to
access the data. GPU waits perform inter-context synchronisation and are cheaper
as they don't require CPU intervention.
There is a possibility that the _get_caps impl will be called with the
feature in the filter caps which when interecting with the template,
will return EMPTY and therefore fail negotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=757854
One may not have an GstGLContext available or current in the thread where one
would need to update the shader. Support this by signalling create-shader
whenever the one-shot 'update-shader' is set to TRUE.
Implemented with videotestsrc ! glshader ! glupload ! gtkglsink
Errors on an invalid shader compilation are ignored however any error
provided by the glsl compiler is printed to stdout.
A GstGLShader is now simply a collection of stages that are
compiled and linked together into a program. The uniform/attribute
interface has remained the same.
In case the format changed fast and the pending format is different
than the currently set but the currently set is equal to the pending
one we could end up having mismatch between the finally set format
and the data stream format.
https://bugzilla.gnome.org/show_bug.cgi?id=755542
We need to keep the active buffer (the one we have retreive a
texture id from) otherwise it's racy and upstream may upload
new content before we have rendered or during later redisplay.
They require to get_proc_address some functions through the
platform specific {glX,egl}GetProcAddress rather than the default
GL library symbol lookup.
Document that "widget" property must be accessed from the
main thread (where GTK is running). This is the same for
state transition on these elements. It is very natural to
do so un GTK applications.
This is a "pseudo" base class. Basically it's a shared instance
and class structure and a shared set of function between the
two widget. It cannot have it's own type like normal base class
since the one instance will implement GtkGLArea while the other
implements GtkDrawingAreay. To workaround this, the parent instance
and class is a union of both.
https://bugzilla.gnome.org/show_bug.cgi?id=752441
Move back the default property at the same place they are in the
other sink. This helps when using a diff viewer to synchronized
this unfortunate copy paste.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
In GTK dispose can be called before the last ref is reached. This
happens when you close the container window. The dispose will be
explicitly called, and destroyed notify will be fired. This patch
fixes this race by properly tracking the widget state.
In the sink, we now set the widget pointer to NULL, so the widget
will properly get created again if you set your pipeline to NULL
state after the widget was destroy, and set it back to PLAYING.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
