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 3653c5b1)

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 750e5668)

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 624dea20)

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 f63381f2)

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 e947c713)

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"

(cherry picked from commit c34e8bb0)

(cherry picked from commit b9afd31b)

(cherry picked from commit 7003bd0b)

(cherry picked from commit 9cdaf2e8)

(cherry picked from commit 857f9d33)

(cherry picked from commit af265ab5)

(cherry picked from commit 1b7743f0)

(cherry picked from commit 93d7defa)

(cherry picked from commit 38201324)

Link to SDL.lib and SDLmain.lib if Cogl was built with the SDL winsys.

Recent changes to the SDL winsys introduced a direct dependency to
SDLmain.lib (and hence SDL.lib) when programs are built, causing linker
errors to appear when any programs using cogl (with the SDL winsys built
in) are built.

Since we cannot determine whether a Cogl build is built with the SDL winsys
at build time easily, we could use #pragma comment (lib, ...) whenever
cogl-sdl.h is included by cogl.h so that SDLmain.lib and SDL.lib is linked
into the resulting binary, so that the program can link and run correctly.

This does not add any external dependencies as the Cogl DLL already depends
on SDL.dll when it is built with the SDL winsys.

https://bugzilla.gnome.org/show_bug.cgi?id=682071

(cherry picked from commit 2921d2a4)

(cherry picked from commit 829e090d)

(cherry picked from commit 1a39fb66)

(cherry picked from commit bb5220db)

Link to SDL.lib and SDLmain.lib if Cogl was built with the SDL winsys.

Recent changes to the SDL winsys introduced a direct dependency to
SDLmain.lib (and hence SDL.lib) when programs are built, causing linker
errors to appear when any programs using cogl (with the SDL winsys built
in) are built.

Since we cannot determine whether a Cogl build is built with the SDL winsys
at build time easily, we could use #pragma comment (lib, ...) whenever
cogl-sdl.h is included by cogl.h so that SDLmain.lib and SDL.lib is linked
into the resulting binary, so that the program can link and run correctly.

This does not add any external dependencies as the Cogl DLL already depends
on SDL.dll when it is built with the SDL winsys.