isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-10 07:56:14 -05:00
Code Issues Packages Projects Releases Wiki Activity
2582fa1519
mutter/cogl/winsys/cogl-winsys-sdl2.c

453 lines
14 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"
typedef struct _CoglContextSdl2
{
SDL_Window *current_window;
} CoglContextSdl2;
typedef struct _CoglRendererSdl2
{
int stub;
} CoglRendererSdl2;
typedef struct _CoglDisplaySdl2
{
SDL_Window *dummy_window;
SDL_GLContext *context;
} CoglDisplaySdl2;
typedef struct _CoglOnscreenSdl2
{
SDL_Window *window;
} CoglOnscreenSdl2;
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,
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_WINSYS_ERROR_INIT,
"SDL_Init failed: %s",
SDL_GetError ());
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)
SDL_GL_SetAttribute (SDL_GL_CONTEXT_MAJOR_VERSION, 3);
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,
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_WINSYS_ERROR_INIT,
"SDL_CreateWindow failed: %s",
SDL_GetError ());
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,
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_WINSYS_ERROR_INIT,
"SDL_GL_CreateContext failed: %s",
SDL_GetError ());
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,
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_WINSYS_ERROR_INIT,
"The GL driver was requested but SDL is using GLES");
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
if (gl_version[0] >= '3')
{
if (display->renderer->driver == COGL_DRIVER_GL)
{
_cogl_set_error (error, COGL_WINSYS_ERROR,
COGL_WINSYS_ERROR_INIT,
"The GL driver was requested but SDL is using "
"GL %c", gl_version[0]);
goto error;
}
}
else
{
if (display->renderer->driver == COGL_DRIVER_GL3)
{
_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 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,
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_WINSYS_ERROR_INIT,
"The GLES2 driver was requested but SDL is "
"not using GLES2");
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,
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_WINSYS_ERROR_INIT,
"The GLES1 driver was requested but SDL is "
"not using GLES1");
goto error;
}
break;
default:
g_assert_not_reached ();
}
return TRUE;
error:
_cogl_winsys_display_destroy (display);
return FALSE;
}
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);
return TRUE;
}
static void
_cogl_winsys_context_deinit (CoglContext *context)
{
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_context->current_window = NULL;
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;
width = cogl_framebuffer_get_width (framebuffer);
height = cogl_framebuffer_get_height (framebuffer);
window = SDL_CreateWindow ("" /* title */,
0, 0, /* x/y */
width, height,
SDL_WINDOW_OPENGL |
SDL_WINDOW_HIDDEN);
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,
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_WINSYS_ERROR_CREATE_ONSCREEN,
"SDL_CreateWindow failed: %s",
SDL_GetError ());
return FALSE;
}
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);
}
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;
vtable_inited = TRUE;
}
return &vtable;
}
Reference in New Issue Copy Permalink