These days cogl/ has a non-recursive Makefile.am and an old one was
still present in cogl/driver.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e1db8e38be72f5372e9d7571a3faec5039e0e6d0)
As a convenience for debugging this adds a cogl_debug_matrix_print
function that prints out the components of a matrix and any internal
flags associated with the given matrix.
(cherry picked from commit 3b33889ff1204f19347a9548320ba95baa54c18c)
This adds a new public cogl_texture_rectangle_new_from_foreign()
function so that we can look at removing the generic
cogl_texture_new_from_foreign().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit af02792b336bb492c5bd11afc34a5dcd417503f6)
To delimit which symbols were considered experimental we used to use
some preprocessor defines to gives experimental symbols an _EXP suffix
so that anyone monitoring the ABI for changes would easily be able to
discount changes made to clearly experimental functions.
These days we simply rely on the gtk-doc "Stability: unstable"
annotation to serve this purpose because changing the actual symbol name
made it slightly more awkward to debug Cogl using GDB and was an extra
mechanical step we decided we could do without.
This patch removes the last remaining _EXP suffix defines in Cogl
(cherry picked from commit 5a1c4a979e00accd492097cfb8f6a8d0fd8331bc)
This splits out most of the OpenGL specific code from cogl-framebuffer.c
into cogl-framebuffer-gl.c and extends the CoglDriverVtable interface
for cogl-framebuffer.c to use.
There are hopes to support several different backends for Cogl
eventually to hopefully get us closer to the metal so this makes some
progress in organizing which parts of Cogl are OpenGL specific so these
parts can potentially be switched out later.
The only remaining use of OpenGL still in cogl-framebuffer.c is to
handle cogl_framebuffer_read_pixels.
This commit introduces some new framebuffer api to be able to
enable texture based depth buffers for a framebuffer (currently
only supported for offscreen framebuffers) and once allocated
to be able to retrieve the depth buffer as a texture for further
usage, say, to implement shadow mapping.
The API works as follow:
* Before the framebuffer is allocated, you can request that a depth
texture is created with
cogl_framebuffer_set_depth_texture_enabled()
* cogl_framebuffer_get_depth_texture() can then be used to grab a
CoglTexture once the framebuffer has been allocated.
glBlitFramebuffer is affected by the scissor so we need to ensure
there is an empty clip flushed before using it. This is similar to
what is done in _cogl_blit_framebuffer().
https://bugzilla.gnome.org/show_bug.cgi?id=690451
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
(cherry picked from commit 65da3f88af9c7b8d72758d116c2652aff68195c1)
The automagic paragraph support of gtk-doc is way too simple to support
things like multi-paragraphs <note>s. Let's trick gtk-doc and make it
generate a valid docbook snippet for cogl-context.
Without this, cogl-context remains absent of the reference
documentation, how sad is this?!
(cherry picked from commit 606b472d91450e3221da6631020f534892e866a9)
Like the Visual Studio 2010 builds, the install project needs to be split
into two, one for the WGL-only configs and another for the WGL+SDL
configs, so that the Cogl and Cogl-Pango DLLs and LIBs can be correctly
copied during the "install" stage, as the resulting DLLs for all configs
land in {Release|Debug}\{Win32|x64}\bin.
Checking whether src_rgb != src_alpha twice is pointless; not checking
whether dst_rgb != dst_alpha is clearly wrong.
Found by Coverity.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=689850
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit fc292c25db3004543e277d92693ab9cb388d2121)
vtable
(Sorry, I had to re-apply Neil's patch as the original one somehow did
not apply)
The function prototypes for the GL functions in CoglContext have the
GLAPIENTRY attribute which on Windows makes them use the stdcall
calling convention. The function pointers exposed from cogl-gles2.h
don't have GLAPIENTRY so they end up having a different calling
convention on Windows. When Cogl is compiled there it ends up giving a
lot of warnings because it assigns a pointer to an incompatible
function type.
We probably don't want to make the functions exposed in cogl-gles2.h
use the stdcall calling convention because we control that API so
there is no need to introduce a second calling convention. The GLES2
context support currently isn't going to work on Windows anyway
because there is no EGL or GLES2 implementation.
Eventually if we make the Cogl GLES2 context virtualized on top of
Cogl then we will provide our own implementations of all these
functions so we can easily keep the C calling convention even on
Windows.
Until then to avoid the warnings on Windows we can just cast the
function pointers temporarily to (void*) when filling in the vtable.
This will also fix the build on Windows using Visual Studio, as it is
more picky on calling convention mismatches.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The ‘length’ for the swap chain is initially -1 which is supposed to
mean ‘no preference’. However, both of the SDL winsys's were
explicitly setting the SDL_GL_DOUBLEBUFFER attribute to zero in that
case which would try to disable double buffering.
On OS X, the equivalent to eglSwapBuffers (ie, [NSOpenGLContext
flushBuffer]) does nothing for a single buffer context. The
cogl-sdl-hello example does not specify the swap chain length so
presumably it would end up with a single buffer config. When
cogl_onscreen_swap_buffers is called it therefore does nothing and
nothing is painted.
I guess to make single-buffered contexts actually useful we should
expose some public equivalent to glFlush so that you can ensure the
rendering commands will actually hit the buffer. Alternatively we
could document that cogl_onscreen_swap_buffers performs this task on
single-buffered configs and then we could make the SDL winsys
explicitly call glFlush in that case.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 71e57f99002d5dee79bbd44b3bc57712b99acb55)
Previously when pushing the GLES2 context with an onscreen framebuffer
it would just call bind_onscreen. This actually binds it with Cogl's
context so presumably the context isolation wasn't working properly.
This patch splits out bind_onscreen to have a second function called
bind_onscreen_with_context that explicitly takes the EGL context to
use. Cogl now uses this when pushing the GLES2 context.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 3653c5b10058a3f79900eb2644cb30f4cf1ca47e)
There was a FIXME comment about making glCopyTex{Sub,}Image2D work
with CoglOffscreen buffers. This has already been fixed so we should
remove the comment.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 750e5668ee64a315c8090dd2223334b1e04bee54)
Previously, Cogl was advertising the GLES2 context feature whenever
the EGL winsys was used, even if the winsys was used with the GL
driver. This wasn't working because when the GL context is created the
API is set to GL with eglBindAPI and it is never changed back to GLES
when the GLES2 context is created. That meant that the created context
is actually GL not GLES2. Any rendering would then fail because the GL
context does not understand the precision statement.
It could be possible to fix it so that it will set the API correctly
before creating the context. It would then also need to reset the API
and unbind the previous context whenever switching between GLES2 and
GL contexts. If the context isn't unbound first then eglMakeCurrent
will actually try to bind both contexts at the same time and at least
Mesa detects this situation and reports that the two contexts
conflict. Presumably we would also need to do something more clever
when we retrieve the function pointers for the GLES2 context.
Currently we just copy them from the CoglContext but if the context is
using the GL driver then this would mean the functions came from libGL
not libGLESv2.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 624dea207cf76ae9ccd7f57c4ebd15d3bd65bff0)
The list of extension names in COGL_EXT_BEGIN should be a zero
separated list of strings which is terminated by an empty string. The
name for the GL_ARB_shader_objects extension was missing the zero
separator so presumably it was relying on the following byte to happen
to be a zero in order not to crash.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f63381f23fa8b0b17e030561940b8a38efff221f)
Previously when Cogl detects that the GLX context is indirect it
resets the function pointers for the VBLANK_COUNTER feature to NULL.
However it wasn't removing the VBLANK_COUNTER feature flag. Some other
parts of the winsys check for that feature flag rather than checking
whether the pointer is NULL so it would end up calling an invalid
function pointer and crashing. This just fixes it to also clear the
feature flag.
https://bugzilla.gnome.org/show_bug.cgi?id=684917
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e947c713a541086f80a308d22774229f0720196a)
Since commit 7253c5ca (Bug 682071-cogl/cogl-sdl.h: MSVC: Link to SDL when
apps are built), on Visual C++ we link to SDL.lib and SDLmain.lib using
a #pragma comment directive in cogl/cogl-sdl.h, so we no longer need
specific project configs for Cogl programs which build against a Cogl built
with SDL. This removes those unneeded configs.
Also "install" cogl/cogl-sdl.h when Cogl is built with the SDL winsys, as
it is a needed header
-Make "install" parts for VS9 and VS10 more consistent with each other
-Create the .def files in the respective intermediate/.obj folders, so that
it is cleaner duringg the build
-Make up for missed files to "install"
