glGetIntegerv (GL_DEPTH_BITS, ...) and friends are deprecated in GL3; we
have to use glGetFramebufferAttachmentParameteriv() instead, like we do
for offscreen framebuffers.
Based on a patch by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=753295
We want to be able to retrieve the XVisualInfo used when creating the
GL context under GLX and EGL-X11, so that we can use the visual before
we have an onscreen frame buffer.
Initialize variables; GCC does not always catch all cases where the
variables are used after being initialized, especially when it comes to
out parameters.
Some drivers ( like mgag200 ) don't yet support drmModePageFlip.
This commit forgoes waiting for vblank and flips right away
in those cases. That prevents the hardware from freezing up the screen,
but does mean there will be some visible tearing.
https://bugzilla.gnome.org/show_bug.cgi?id=746042
We can't just destroy and replace the EGL and gbm surfaces while
they are still in use i.e. while there is a pending flip. In fact, in
that case, we were calling gbm_surface_destroy() on a surface that
still had the front buffer locked and then, on the flip handler,
gbm_surface_release_buffer() for a buffer that didn't belong to the
new surface.
Instead, we still allocate new surfaces when requested but they only
replace the old ones on the next swap buffers when we're sure that the
previous flip has been handled and buffers properly released.
Currently the code queries the current msc then tries to approximate the
value of the next msc satisfing the modulus 2 for when to wait. This
introduces some instability as the msc may tick over during the
roundtrip leading to a 32ms wait instead of a 16ms wait. This happens
often enough to cause jerky animations, and affect gnome-shell-perf-tool.
A simpler solution is just use a single roundtrip by using WaitForMsc to
ask the driver to compute the next vblank itself.
Cc: Owen W. Taylor <otaylor@fishsoup.net>
Cc: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Robert Bragg <robert@sixbynine.org>
Add cogl_texture_pixmap_x11_new_left() and
cogl_texture_pixmap_x11_new_right() (which takes the left texture
as an argument) for texture pixmap rendering with stereo content.
The underlying GLXPixmap is created using a stereo visual and shared
between the left and right textures.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
If we want to show quad-buffer stereo with Cogl, we need to pick an
appropriate fbconfig for creating the CoglOnscreen objects. Add
cogl_onscreen_template_set_stereo_enabled() to indicate whether
stereo support is needed.
Add cogl_framebuffer_get_stereo_mode() to see if a framebuffer was
created with stereo support.
Add cogl_framebuffer_get_stereo_mode() to pick whether to draw to
the left, right, or both buffers.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
An application might for whatever reason want to control a specific output
directly and have cogl only swap the other outputs if any. So add an api that
allows setting a crtc to be ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=730536
The surfaceless context extension can be used to bind a context
without a surface. We can use this to avoid creating a dummy surface
when the CoglContext is first created. Otherwise we have to have the
dummy surface so that we can bind it before the first onscreen is
created.
The main awkward part of this patch is that theoretically according to
the GL and GLES spec if you first bind a context without a surface
then the default state for glDrawBuffers is GL_NONE instead of
GL_BACK. In practice Mesa doesn't seem to do this but we need to be
robust against a GL implementation that does. Therefore we track when
the CoglContext is first used with a CoglOnscreen and force the
glDrawBuffers state to be GL_BACK.
There is a further awkward part in that GLES2 doesn't actually have a
glDrawBuffers state but GLES3 does. GLES3 also defaults to GL_NONE in
this case so if GLES3 is available then we have to be sure to set the
state to GL_BACK. As far as I can tell that actually makes GLES3
incompatible with GLES2 because in theory if the application is not
aware of GLES3 then it should be able to assume the draw buffer is
always GL_BACK.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
(cherry picked from commit e5f28f1e75db9bdc4f2688f420a74f908f96cf76)
Conflicts:
cogl/winsys/cogl-winsys-egl-kms.c
cogl/winsys/cogl-winsys-egl-x11.c
