The use of mediump as a specifier in GLSL shaders will have limited
resolution and when used as texture coordinates may become inaccurate
over texture sizes of 1024.
This reverts commit 69c3c31608.
All devices have the same name, they are duplicated with pulseaudio one
and the provided does not respond to HW being plugged/unplugged. I think
it's not ready for 1.16.
Binding the vertex array to 0 will unbind everything else already.
In the previous order older versions of the Intel GL driver caused
errors to be printed for every single call when disabling the vertex
attrib arrays after binding the vertex array to 0.
It might be the case that glgsinkbin would try to set a property to
its internal sink which doesn't exist in it, leading to a glib's
warning. For example, when playsink sets 'force-aspect-ratio' property
and glsinkbin has, as internal sink, appsink, which doesn't handle
that property.
The patch validates the incoming property to forward to internal sink
if it exists in the internal sink and both properties has the same
type.
Running the context query in _start and during the NULL->READY state transition
can fail because downstream elements might not be able to answer and thus the
source element would not be able to reuse downstream GLContext and GLDisplay.
This issue happened specifically when trying to use gltestsrc in playbin.
Without this, a buffer is dropped if glupload indicates that it is
necessary to reconfigure.
Avoid this by explicitly reconfiguring immediately and uploading the buffer
again.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
Fixes the internal viewconvert to not scale buffers for output with the
following pipeline:
gltestsrc ! glimagesink
It also fixes overlay composition with a resized output with an OpenGL
upstream:
gltestsrc ! timeoverlay ! glimagesink
Attempting to use the MAX(1, display_rect) would result in the overlay
composition attempting to draw into 1x1 buffer and calculate some
grossly incorrect sizes.
previously failing case:
gltestsrc ! textoverlay text=GStreamer ! glimagesinkelement
... instead of waiting for the first non-header buffer.
Also drop non-identification headers arriving after initialization or
before the identification header. We don't do anything with them and
they would just accumulate.
https://bugzilla.gnome.org/show_bug.cgi?id=796980
The argument 0x0 is interpreted by the x86 compiler as a 32-bit int, but
it is consumed as a 64-bit uint causing a segmentation fault. We need to
explicit cast it to guint64 in order for the va_list to be built correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=797092
Without this, a buffer is dropped if glupload indicates that it is
necessary to reconfigure.
Avoid this by explicitly reconfiguring immediately and uploading the buffer
again.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
It makes sense to control it explicitly to allow us to enable it on
platforms that don't have hardware floating-point, and to allow people
to enable the 'vorbis' plugin without having to also provide the
Tremor dependency which is useless on most devices.
And clean up any old pending headers if we receive a new identification
header, or if we receive a new set of headers via caps.
Otherwise it might happen that we receive one or more header but not
all, and then afterwards all headers again, and libvorbis does not like
getting headers passed multiple times and would error out.
It only makes sense to pass the very latest headers to the decoder at
the time we can actually make use of them.
https://bugzilla.gnome.org/show_bug.cgi?id=796980
PangoCairo is thread-safe as long as the context and fontmap are not
shared between threads. Previously each subclass had its own context and
a class mutex for this reason, but apart from hurting performance this
was also not completely safe yet: the same fontmap might've been used by
different classes from different threads as the thread-default fontmap
(at time of class initialization) was used.
This effectively (but optionally) requires libjpeg-turbo which
ships with a .pc file and is what pretty much everyone these days
uses anyway for libjpeg, so shouldn't be a problem hopefully.
https://bugzilla.gnome.org/show_bug.cgi?id=796947
