brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
88d8bd84f2
mutter/cogl/winsys/cogl-winsys-sdl2.c

579 lines
18 KiB
C
Raw Normal View History

Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2011, 2012 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
*
* Authors:
* Neil Roberts <neil@linux.intel.com>
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <SDL.h>
#include "cogl-renderer-private.h"
#include "cogl-display-private.h"
#include "cogl-framebuffer-private.h"
#include "cogl-swap-chain-private.h"
#include "cogl-onscreen-template-private.h"
#include "cogl-context-private.h"
#include "cogl-onscreen-private.h"
#include "cogl-winsys-sdl-private.h"
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
#include "cogl-error-private.h"
Add cogl_sdl_onscreen_get_window() This adds a function to get a pointer to the SDL_Window associated with a CoglOnscreen when using the SDL2 winsys. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 071f4b80daa8a2f967746a30b3acf014d74f781a)
2012-11-26 08:07:36 -05:00
#include "cogl-sdl.h"
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
typedef struct _CoglContextSdl2
{
SDL_Window *current_window;
} CoglContextSdl2;
typedef struct _CoglRendererSdl2
{
int stub;
} CoglRendererSdl2;
typedef struct _CoglDisplaySdl2
{
SDL_Window *dummy_window;
SDL_GLContext *context;
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
CoglBool pending_resize_notify;
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
} CoglDisplaySdl2;
typedef struct _CoglOnscreenSdl2
{
SDL_Window *window;
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
CoglBool pending_resize_notify;
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
} CoglOnscreenSdl2;
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
/* The key used to store a pointer to the CoglOnscreen in an
* SDL_Window */
#define COGL_SDL_WINDOW_DATA_KEY "cogl-onscreen"
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
static CoglFuncPtr
_cogl_winsys_renderer_get_proc_address (CoglRenderer *renderer,
Don't use eglGetProcAddress to retrieve core functions According to the EGL spec, eglGetProcAddress should only be used to retrieve extension functions. It also says that returning non-NULL does not mean the extension is available so you could interpret this as saying that the function is allowed to return garbage for core functions. This seems to happen at least for the Android implementation of EGL. To workaround this the winsys's are now passed down a flag to say whether the function is from the core API. This information is already in the gl-prototypes headers as the minimum core GL version and as a pair of flags to specify whether it is available in core GLES1 and GLES2. If the function is in core the EGL winsys will now avoid using eglGetProcAddress and always fallback to querying the library directly with the GModule API. The GLX winsys is left alone because glXGetProcAddress apparently supports querying core API and extension functions. The WGL winsys could ideally be changed because wglGetProcAddress should also only be used for extension functions but the situation is slightly different because WGL considers anything from GL > 1.1 to be an extension so it would need a bit more information to determine whether to query the function directly from the library. The SDL winsys is also left alone because it's not as easy to portably determine which GL library SDL has chosen to load in order to resolve the symbols directly. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 72089730ad06ccdd38a344279a893965ae68cec1) Since we aren't able to break API on the 1.12 branch cogl_get_proc_address is still supported but isn't easily able to determine whether the given name corresponds to a core symbol or not. For now we just assume the symbol being queried isn't part of the core GL api and update the documentation accordingly.
2012-06-20 07:42:31 -04:00
const char *name,
CoglBool in_core)
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
{
Don't use eglGetProcAddress to retrieve core functions According to the EGL spec, eglGetProcAddress should only be used to retrieve extension functions. It also says that returning non-NULL does not mean the extension is available so you could interpret this as saying that the function is allowed to return garbage for core functions. This seems to happen at least for the Android implementation of EGL. To workaround this the winsys's are now passed down a flag to say whether the function is from the core API. This information is already in the gl-prototypes headers as the minimum core GL version and as a pair of flags to specify whether it is available in core GLES1 and GLES2. If the function is in core the EGL winsys will now avoid using eglGetProcAddress and always fallback to querying the library directly with the GModule API. The GLX winsys is left alone because glXGetProcAddress apparently supports querying core API and extension functions. The WGL winsys could ideally be changed because wglGetProcAddress should also only be used for extension functions but the situation is slightly different because WGL considers anything from GL > 1.1 to be an extension so it would need a bit more information to determine whether to query the function directly from the library. The SDL winsys is also left alone because it's not as easy to portably determine which GL library SDL has chosen to load in order to resolve the symbols directly. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 72089730ad06ccdd38a344279a893965ae68cec1) Since we aren't able to break API on the 1.12 branch cogl_get_proc_address is still supported but isn't easily able to determine whether the given name corresponds to a core symbol or not. For now we just assume the symbol being queried isn't part of the core GL api and update the documentation accordingly.
2012-06-20 07:42:31 -04:00
/* XXX: It's not totally clear whether it's safe to call this for
* core functions. From the code it looks like the implementations
* will fall back to using some form of dlsym if the winsys
* GetProcAddress function returns NULL. Presumably this will work
* in most cases apart from EGL platforms that return invalid
* pointers for core functions. It's awkward for this code to get a
* handle to the GL module that SDL has chosen to load so just
* calling SDL_GL_GetProcAddress is probably the best we can do
* here. */
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
return SDL_GL_GetProcAddress (name);
}
static void
_cogl_winsys_renderer_disconnect (CoglRenderer *renderer)
{
SDL_VideoQuit ();
g_slice_free (CoglRendererSdl2, renderer->winsys);
}
static CoglBool
_cogl_winsys_renderer_connect (CoglRenderer *renderer,
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
CoglError **error)
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
{
if (SDL_VideoInit (NULL) < 0)
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
COGL_WINSYS_ERROR_INIT,
"SDL_Init failed: %s",
SDL_GetError ());
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
return FALSE;
}
renderer->winsys = g_slice_new0 (CoglRendererSdl2);
return TRUE;
}
static void
_cogl_winsys_display_destroy (CoglDisplay *display)
{
CoglDisplaySdl2 *sdl_display = display->winsys;
_COGL_RETURN_IF_FAIL (sdl_display != NULL);
if (sdl_display->context)
SDL_GL_DeleteContext (sdl_display->context);
if (sdl_display->dummy_window)
SDL_DestroyWindow (sdl_display->dummy_window);
g_slice_free (CoglDisplaySdl2, display->winsys);
display->winsys = NULL;
}
static void
set_gl_attribs_from_framebuffer_config (CoglFramebufferConfig *config)
{
SDL_GL_SetAttribute (SDL_GL_RED_SIZE, 1);
SDL_GL_SetAttribute (SDL_GL_GREEN_SIZE, 1);
SDL_GL_SetAttribute (SDL_GL_BLUE_SIZE, 1);
SDL_GL_SetAttribute (SDL_GL_DEPTH_SIZE, 1);
SDL_GL_SetAttribute (SDL_GL_STENCIL_SIZE,
config->need_stencil ? 1 : 0);
sdl: Don't set SDL_GL_DOUBLEBUFFER when the swap chain has no pref 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)
2012-11-13 07:10:13 -05:00
if (config->swap_chain->length >= 0)
SDL_GL_SetAttribute (SDL_GL_DOUBLEBUFFER,
config->swap_chain->length > 1 ? 1 : 0);
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
SDL_GL_SetAttribute (SDL_GL_ALPHA_SIZE,
config->swap_chain->has_alpha ? 1 : 0);
}
static CoglBool
_cogl_winsys_display_setup (CoglDisplay *display,
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
CoglError **error)
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
{
CoglDisplaySdl2 *sdl_display;
const char * (* get_string_func) (GLenum name);
const char *gl_version;
_COGL_RETURN_VAL_IF_FAIL (display->winsys == NULL, FALSE);
sdl_display = g_slice_new0 (CoglDisplaySdl2);
display->winsys = sdl_display;
set_gl_attribs_from_framebuffer_config (&display->onscreen_template->config);
if (display->renderer->driver == COGL_DRIVER_GLES1)
SDL_GL_SetAttribute (SDL_GL_CONTEXT_MAJOR_VERSION, 1);
else if (display->renderer->driver == COGL_DRIVER_GLES2)
SDL_GL_SetAttribute (SDL_GL_CONTEXT_MAJOR_VERSION, 2);
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
else if (display->renderer->driver == COGL_DRIVER_GL3)
sdl2: Fix GL3 context creation The check to verify whether we've got the right GL context was checking that the GL version was less than 3 whenever the non-GL3 driver is used. However it looks like the driver is free to return a GL3 context that is compatible with GL2 if GL2 is requested so this was breaking the GL2 driver. This also adds the necessary SDL attributes to request a forward compatible core context like the GLX and EGL winsys's do. I haven't actually tested this because it looks like SDL will only create a GL context with GLX and I haven't got a recent enough X server to handle the glXCreateContextAttribs request. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d46acafa3ea7ba2e6c4ac7a45f00a132df1b2872)
2012-10-03 07:06:02 -04:00
{
SDL_GL_SetAttribute (SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute (SDL_GL_CONTEXT_PROFILE_MASK,
SDL_GL_CONTEXT_PROFILE_CORE);
SDL_GL_SetAttribute (SDL_GL_CONTEXT_FLAGS,
SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG);
}
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
/* Create a dummy 1x1 window that never gets display so that we can
* create a GL context */
sdl_display->dummy_window = SDL_CreateWindow ("",
0, 0, /* x/y */
1, 1, /* w/h */
SDL_WINDOW_OPENGL |
SDL_WINDOW_HIDDEN);
if (sdl_display->dummy_window == NULL)
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
COGL_WINSYS_ERROR_INIT,
"SDL_CreateWindow failed: %s",
SDL_GetError ());
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
goto error;
}
sdl_display->context = SDL_GL_CreateContext (sdl_display->dummy_window);
if (sdl_display->context == NULL)
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
COGL_WINSYS_ERROR_INIT,
"SDL_GL_CreateContext failed: %s",
SDL_GetError ());
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
goto error;
}
/* SDL doesn't seem to provide a way to select between GL and GLES
* and instead it will just pick one itself. We can at least try to
* verify that it picked the one we were expecting by looking at the
* GL version string */
get_string_func = SDL_GL_GetProcAddress ("glGetString");
gl_version = get_string_func (GL_VERSION);
switch (display->renderer->driver)
{
case COGL_DRIVER_GL:
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
case COGL_DRIVER_GL3:
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
/* The first character of the version string will be a digit if
* it's normal GL */
if (!g_ascii_isdigit (gl_version[0]))
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
COGL_WINSYS_ERROR_INIT,
"The GL driver was requested but SDL is using GLES");
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
goto error;
}
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
sdl2: Fix GL3 context creation The check to verify whether we've got the right GL context was checking that the GL version was less than 3 whenever the non-GL3 driver is used. However it looks like the driver is free to return a GL3 context that is compatible with GL2 if GL2 is requested so this was breaking the GL2 driver. This also adds the necessary SDL attributes to request a forward compatible core context like the GLX and EGL winsys's do. I haven't actually tested this because it looks like SDL will only create a GL context with GLX and I haven't got a recent enough X server to handle the glXCreateContextAttribs request. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d46acafa3ea7ba2e6c4ac7a45f00a132df1b2872)
2012-10-03 07:06:02 -04:00
if (display->renderer->driver == COGL_DRIVER_GL3 &&
gl_version[0] < '3')
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
{
sdl2: Fix GL3 context creation The check to verify whether we've got the right GL context was checking that the GL version was less than 3 whenever the non-GL3 driver is used. However it looks like the driver is free to return a GL3 context that is compatible with GL2 if GL2 is requested so this was breaking the GL2 driver. This also adds the necessary SDL attributes to request a forward compatible core context like the GLX and EGL winsys's do. I haven't actually tested this because it looks like SDL will only create a GL context with GLX and I haven't got a recent enough X server to handle the glXCreateContextAttribs request. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d46acafa3ea7ba2e6c4ac7a45f00a132df1b2872)
2012-10-03 07:06:02 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
COGL_WINSYS_ERROR_INIT,
"The GL3 driver was requested but SDL is using "
"GL %c", gl_version[0]);
goto error;
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
}
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
break;
case COGL_DRIVER_GLES2:
if (!g_str_has_prefix (gl_version, "OpenGL ES 2"))
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
COGL_WINSYS_ERROR_INIT,
"The GLES2 driver was requested but SDL is "
"not using GLES2");
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
goto error;
}
break;
case COGL_DRIVER_GLES1:
if (!g_str_has_prefix (gl_version, "OpenGL ES 1"))
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
COGL_WINSYS_ERROR_INIT,
"The GLES1 driver was requested but SDL is "
"not using GLES1");
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
goto error;
}
break;
default:
g_assert_not_reached ();
}
return TRUE;
error:
_cogl_winsys_display_destroy (display);
return FALSE;
}
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
static CoglFilterReturn
sdl_event_filter_cb (SDL_Event *event, void *data)
{
if (event->type == SDL_WINDOWEVENT &&
event->window.event == SDL_WINDOWEVENT_SIZE_CHANGED)
{
CoglContext *context = data;
CoglDisplay *display = context->display;
CoglDisplaySdl2 *sdl_display = display->winsys;
float width = event->window.data1;
float height = event->window.data2;
CoglFramebuffer *framebuffer;
CoglOnscreenSdl2 *sdl_onscreen;
SDL_Window *window;
window = SDL_GetWindowFromID (event->window.windowID);
if (window == NULL)
return COGL_FILTER_CONTINUE;
framebuffer = SDL_GetWindowData (window, COGL_SDL_WINDOW_DATA_KEY);
if (framebuffer == NULL || framebuffer->context != context)
return COGL_FILTER_CONTINUE;
_cogl_framebuffer_winsys_update_size (framebuffer, width, height);
sdl_onscreen = COGL_ONSCREEN (framebuffer)->winsys;
/* We only want to notify that a resize happened when the
application calls cogl_context_dispatch so instead of immediately
notifying we'll set a flag to remember to notify later */
sdl_display->pending_resize_notify = TRUE;
sdl_onscreen->pending_resize_notify = TRUE;
return COGL_FILTER_CONTINUE;
}
return COGL_FILTER_CONTINUE;
}
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
static CoglBool
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_winsys_context_init (CoglContext *context, CoglError **error)
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
{
CoglRenderer *renderer = context->display->renderer;
context->winsys = g_new0 (CoglContextSdl2, 1);
if (G_UNLIKELY (renderer->sdl_event_type_set == FALSE))
g_error ("cogl_sdl_renderer_set_event_type() or cogl_sdl_context_new() "
"must be called during initialization");
if (!_cogl_context_update_features (context, error))
return FALSE;
if (SDL_GL_GetSwapInterval () != -1)
COGL_FLAGS_SET (context->winsys_features,
COGL_WINSYS_FEATURE_SWAP_REGION_THROTTLE,
TRUE);
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
_cogl_renderer_add_native_filter (renderer,
(CoglNativeFilterFunc) sdl_event_filter_cb,
context);
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
return TRUE;
}
static void
_cogl_winsys_context_deinit (CoglContext *context)
{
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
CoglRenderer *renderer = context->display->renderer;
_cogl_renderer_remove_native_filter (renderer,
(CoglNativeFilterFunc)
sdl_event_filter_cb,
context);
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
g_free (context->winsys);
}
static void
_cogl_winsys_onscreen_bind (CoglOnscreen *onscreen)
{
CoglFramebuffer *fb = COGL_FRAMEBUFFER (onscreen);
CoglContext *context = fb->context;
CoglContextSdl2 *sdl_context = context->winsys;
CoglDisplaySdl2 *sdl_display = context->display->winsys;
CoglOnscreenSdl2 *sdl_onscreen = onscreen->winsys;
if (sdl_context->current_window == sdl_onscreen->window)
return;
SDL_GL_MakeCurrent (sdl_onscreen->window, sdl_display->context);
sdl_context->current_window = sdl_onscreen->window;
/* It looks like SDL just directly calls a glXSwapInterval function
* when this is called. This may be provided by either the EXT
* extension, the SGI extension or the Mesa extension. The SGI
* extension is per context so we can't just do this once when the
* framebuffer is allocated. See the comments in the GLX winsys for
* more info. */
if (COGL_FLAGS_GET (context->winsys_features,
COGL_WINSYS_FEATURE_SWAP_REGION_THROTTLE))
{
CoglFramebuffer *fb = COGL_FRAMEBUFFER (onscreen);
SDL_GL_SetSwapInterval (fb->config.swap_throttled ? 1 : 0);
}
}
static void
_cogl_winsys_onscreen_deinit (CoglOnscreen *onscreen)
{
CoglOnscreenSdl2 *sdl_onscreen = onscreen->winsys;
if (sdl_onscreen->window != NULL)
{
CoglContext *context = COGL_FRAMEBUFFER (onscreen)->context;
CoglContextSdl2 *sdl_context = context->winsys;
if (sdl_context->current_window == sdl_onscreen->window)
sdl: Bind the default window when currently bound window is destroyed Cogl always needs to have the context bound to something so that it can freely create resources such as textures even if there is no current window. When the currently bound SDLWindow is destroyed, SDL apparently explicitly unbinds the GL context. If something then later for example tries to create a texture Cogl would start getting GL errors and fail. To fix this the SDL winsys now just binds the dummy window before deiniting the currently bound onscreen. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 2c0cfdefbb9d1ac5097d98887d3581b67a324fae)
2012-12-05 14:31:29 -05:00
{
CoglDisplaySdl2 *sdl_display = context->display->winsys;
/* SDL explicitly unbinds the context when the currently
* bound window is destroyed. Cogl always needs a context
* bound so that for example it can create texture resources
* at any time even without flushing a framebuffer.
* Therefore we'll bind the dummy window. */
SDL_GL_MakeCurrent (sdl_display->dummy_window,
sdl_display->context);
sdl_context->current_window = sdl_display->dummy_window;
}
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
SDL_DestroyWindow (sdl_onscreen->window);
sdl_onscreen->window = NULL;
}
g_slice_free (CoglOnscreenSdl2, sdl_onscreen);
onscreen->winsys = NULL;
}
static CoglBool
_cogl_winsys_onscreen_init (CoglOnscreen *onscreen,
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
CoglError **error)
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
{
CoglFramebuffer *framebuffer = COGL_FRAMEBUFFER (onscreen);
CoglOnscreenSdl2 *sdl_onscreen;
SDL_Window *window;
int width, height;
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
SDL_WindowFlags flags;
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
width = cogl_framebuffer_get_width (framebuffer);
height = cogl_framebuffer_get_height (framebuffer);
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
flags = SDL_WINDOW_OPENGL | SDL_WINDOW_HIDDEN;
/* The resizable property on SDL window apparently can only be set
* on creation */
if (onscreen->resizable)
flags |= SDL_WINDOW_RESIZABLE;
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
window = SDL_CreateWindow ("" /* title */,
0, 0, /* x/y */
width, height,
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
flags);
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
if (window == NULL)
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Fix a warning when building the SDL2 winsys The SDL2 winsys was using _cogl_set_error without including its header so it was giving an annoying warning. This patch also fixes some indentation issues. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
2012-10-03 07:03:18 -04:00
COGL_WINSYS_ERROR_CREATE_ONSCREEN,
"SDL_CreateWindow failed: %s",
SDL_GetError ());
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
return FALSE;
}
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
SDL_SetWindowData (window, COGL_SDL_WINDOW_DATA_KEY, onscreen);
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
onscreen->winsys = g_slice_new (CoglOnscreenSdl2);
sdl_onscreen = onscreen->winsys;
sdl_onscreen->window = window;
return TRUE;
}
static void
_cogl_winsys_onscreen_swap_buffers (CoglOnscreen *onscreen)
{
CoglOnscreenSdl2 *sdl_onscreen = onscreen->winsys;
SDL_GL_SwapWindow (sdl_onscreen->window);
}
static void
_cogl_winsys_onscreen_update_swap_throttled (CoglOnscreen *onscreen)
{
CoglContext *context = COGL_FRAMEBUFFER (onscreen)->context;
CoglContextSdl2 *sdl_context = context->winsys;
CoglOnscreenSdl2 *sdl_onscreen = onscreen->winsys;
if (sdl_context->current_window != sdl_onscreen->window)
return;
sdl_context->current_window = NULL;
_cogl_winsys_onscreen_bind (onscreen);
}
static void
_cogl_winsys_onscreen_set_visibility (CoglOnscreen *onscreen,
CoglBool visibility)
{
CoglOnscreenSdl2 *sdl_onscreen = onscreen->winsys;
if (visibility)
SDL_ShowWindow (sdl_onscreen->window);
else
SDL_HideWindow (sdl_onscreen->window);
}
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
static void
flush_pending_notifications_cb (void *data,
void *user_data)
{
CoglFramebuffer *framebuffer = data;
if (framebuffer->type == COGL_FRAMEBUFFER_TYPE_ONSCREEN)
{
CoglOnscreen *onscreen = COGL_ONSCREEN (framebuffer);
CoglOnscreenSdl2 *sdl_onscreen = onscreen->winsys;
if (sdl_onscreen->pending_resize_notify)
{
_cogl_onscreen_notify_resize (onscreen);
sdl_onscreen->pending_resize_notify = FALSE;
}
}
}
static void
_cogl_winsys_poll_dispatch (CoglContext *context,
const CoglPollFD *poll_fds,
int n_poll_fds)
{
CoglDisplay *display = context->display;
CoglDisplaySdl2 *sdl_display = display->winsys;
if (sdl_display->pending_resize_notify)
{
g_list_foreach (context->framebuffers,
flush_pending_notifications_cb,
NULL);
sdl_display->pending_resize_notify = FALSE;
}
}
Add cogl_sdl_onscreen_get_window() This adds a function to get a pointer to the SDL_Window associated with a CoglOnscreen when using the SDL2 winsys. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 071f4b80daa8a2f967746a30b3acf014d74f781a)
2012-11-26 08:07:36 -05:00
SDL_Window *
cogl_sdl_onscreen_get_window (CoglOnscreen *onscreen)
{
CoglOnscreenSdl2 *sdl_onscreen;
_COGL_RETURN_VAL_IF_FAIL (cogl_is_onscreen (onscreen), NULL);
if (!cogl_framebuffer_allocate (COGL_FRAMEBUFFER (onscreen), NULL))
return NULL;
sdl_onscreen = onscreen->winsys;
return sdl_onscreen->window;
}
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
const CoglWinsysVtable *
_cogl_winsys_sdl_get_vtable (void)
{
static CoglBool vtable_inited = FALSE;
static CoglWinsysVtable vtable;
/* It would be nice if we could use C99 struct initializers here
like the GLX backend does. However this code is more likely to be
compiled using Visual Studio which (still!) doesn't support them
so we initialize it in code instead */
if (!vtable_inited)
{
memset (&vtable, 0, sizeof (vtable));
vtable.id = COGL_WINSYS_ID_SDL;
vtable.name = "SDL";
vtable.renderer_get_proc_address = _cogl_winsys_renderer_get_proc_address;
vtable.renderer_connect = _cogl_winsys_renderer_connect;
vtable.renderer_disconnect = _cogl_winsys_renderer_disconnect;
vtable.display_setup = _cogl_winsys_display_setup;
vtable.display_destroy = _cogl_winsys_display_destroy;
vtable.context_init = _cogl_winsys_context_init;
vtable.context_deinit = _cogl_winsys_context_deinit;
vtable.onscreen_init = _cogl_winsys_onscreen_init;
vtable.onscreen_deinit = _cogl_winsys_onscreen_deinit;
vtable.onscreen_bind = _cogl_winsys_onscreen_bind;
vtable.onscreen_swap_buffers = _cogl_winsys_onscreen_swap_buffers;
vtable.onscreen_update_swap_throttled =
_cogl_winsys_onscreen_update_swap_throttled;
vtable.onscreen_set_visibility = _cogl_winsys_onscreen_set_visibility;
Support window resizing in the SDL 2 winsys The SDL2 winsys will now set the SDL_WINDOW_RESIZABLE flag on the window before creating it if the resizable property is set on the onscreen. Note that there doesn't appear to be a way in SDL to change the flag later so unlike the other winsyses it will only take affect if it is set before allocating the framebuffer. The winsys now registers a callback for SDL events so that it can report window size changes back to the application. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 0dea9aeb897faf029828379b120970477df3c7d5)
2012-06-27 10:49:38 -04:00
vtable.poll_dispatch = _cogl_winsys_poll_dispatch;
Add an SDL2 winsys This adds an alternate version of the SDL winsys using the SDL 2 API. The two versions are mutually exclusive and share the same CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl because it supports multiple windows and the video subsystem can be initialised entirely independently of the rest of the subsystems. The SDL2 winsys creates an invisible dummy window in order to bind the GL context after creating the Cogl display. This is similar to how the X11 winsys's work. SDL2 seems to support compiling with support for both GL and GLES. However there doesn't seem to be a way to select between the two backends outside of SDL. In fact if you do compile them both in it seems to break down because it will always try to use the window system functions from the GLES backend because those are filled in second in the vtable. However when creating the window it will always prefer to use the GL function to choose a visual. This function gets confused because the GL backend has not been initialised at that point. The Cogl backend therefore just leaves it up to SDL to pick a sensible backend. It will then verify that it picked a GL library which matches the Cogl driver by checking the string from glGetString(GL_VERSION). Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
2012-06-14 09:42:16 -04:00
vtable_inited = TRUE;
}
return &vtable;
}
Reference in New Issue Copy Permalink