isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-12-25 12:32:05 +00:00
Code Issues Packages Projects Releases Wiki Activity
4e55e79c2b
mutter/cogl/cogl-renderer.c

476 lines
12 KiB
C
Raw Normal View History

Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2011 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, write to the
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
* Boston, MA 02111-1307, USA.
*
* Authors:
* Robert Bragg <robert@linux.intel.com>
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
winsys: Expose environment variable to choose winsys This makes it possible to override the winsys that cogl uses by setting the COGL_RENDERER environment variable e.g. to "GLX" or "EGL"
2011-04-18 15:24:51 +00:00
#include <stdlib.h>
#include <string.h>
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
#include "cogl.h"
Start to reduce dependence on glib Since we've had several developers from admirable projects say they would like to use Cogl but would really prefer not to pull in gobject,gmodule and glib as extra dependencies we are investigating if we can get to the point where glib is only an optional dependency. Actually we feel like we only make minimal use of glib anyway, so it may well be quite straightforward to achieve this. This adds a --disable-glib configure option that can be used to disable features that depend on glib. Actually --disable-glib doesn't strictly disable glib at this point because it's more helpful if cogl continues to build as we make incremental progress towards this. The first use of glib that this patch tackles is the use of g_return_val_if_fail and g_return_if_fail which have been replaced with equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 21:34:30 +00:00
#include "cogl-util.h"
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
#include "cogl-internal.h"
Add internal _cogl_init() function This adds a _cogl_init function for Cogl that we expect to be the first thing called before anything else is done with Cogl. It's not a public API so it's expected that all entry points for Cogl that might be the first function used should call _cogl_init(). We currently call _cogl_init() in these functions: cogl_renderer_new cogl_display_new cogl_context_new cogl_android_set_native_window _cogl_init() can be called multiple times, and only the first call has any affect. For example _cogl_init() gives us a place check and parse the COGL_DEBUG environment variable. Since we don't have any need to parse command line arguments (we can always get user configuration options from the environment) our init function doesn't require argc/argv pointers. By saying up front that we aren't interested in command line arguments that means we can avoid the mess that is GOption based library initialization which is extremely fragile due to its lack of dependency tracking between modules. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-14 21:33:44 +00:00
#include "cogl-private.h"
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
#include "cogl-object.h"
renderer: Add cogl_renderer_get_n_fragment_texture_units() Add a method on the renderer to know how many texture image units are accessible from fragment shaders. https://bugzilla.gnome.org/show_bug.cgi?id=657347 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-08-25 16:26:44 +00:00
#include "cogl-context-private.h"
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
#include "cogl-renderer.h"
#include "cogl-renderer-private.h"
#include "cogl-display-private.h"
#include "cogl-winsys-private.h"
Make stub winsys into a proper winsys backend Instead of the stub winsys being a special case set of #ifdef'd code used when COGL_HAS_FULL_WINSYS wasn't defined, the stub winsys now implements a CoglWinsysVtable like all other winsys backends (it's just that everything is a NOP). This way we can get rid of the COGL_HAS_FULL_WINSYS define and also the stub winsys can be runtime selected whereas before it was incompatible with all other winsys backends.
2011-05-17 14:00:38 +00:00
#include "cogl-winsys-stub-private.h"
cogl: Add support for reading a cogl.conf config file When cogl initializes we now check for a cogl/cogl.conf in any of the system config dirs (determined using $XDG_CONFIG_DIRS on linux) we then also check the user's config directory (determined using XDG_CONFIG_HOME on linux) for a cogl/cogl.conf file. Options specified in the user config file have priority over the system config options. The config file has an .ini style syntax with a mandatory [global] section and we currently understand 3 keynames: COGL_DEBUG, COGL_DRIVER and COGL_RENDERER which have the same semantics as the corresponding environment variables. Options set using the environment variables have priority over options set in the config files. To allow users to undo the enabling of debug options in config files this patch also adds a check for COGL_NO_DEBUG environment variable which will disable the specified options which may have been enabled in config files. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-03 17:15:54 +00:00
#include "cogl-config-private.h"
cogl-renderer.c: Fix includes Only include cogl-xlib-renderer.h when XLIB support is available Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-09 07:19:26 +00:00
Rename the EGL_X11 winsys to EGL_XLIB Eventually we might want to have an XCB-based EGL winsys. We already have xlib-specific API in CoglRenderer (eg, to set a foreign display) so the application needs to be able to specifically select between XCB and XLIB. This also removes the POWERVR part while renaming COGL_HAS_EGL_PLATFORM_POWERVR_X11_SUPPORT to COGL_HAS_EGL_PLATFORM_XLIB_SUPPORT because the winsys is equally applicable to Mesa. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-13 16:23:25 +00:00
#ifdef COGL_HAS_EGL_PLATFORM_XLIB_SUPPORT
Add a separate winsys vtable for each EGL platform Instead of just having an "EGL" renderer, there is now a separate winsys for each platform. Currently they just directly copy the vtable for the EGL platform so it is still only possible to have one EGL platform compiled into Cogl. However the intention is that the winsys-specific code for each platform will be moved into override functions in the corresponding platform winsys. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-08 17:24:40 +00:00
#include "cogl-winsys-egl-x11-private.h"
#endif
#ifdef COGL_HAS_EGL_PLATFORM_WAYLAND_SUPPORT
#include "cogl-winsys-egl-wayland-private.h"
#endif
#ifdef COGL_HAS_EGL_PLATFORM_KMS_SUPPORT
#include "cogl-winsys-egl-kms-private.h"
#endif
#ifdef COGL_HAS_EGL_PLATFORM_GDL_SUPPORT
#include "cogl-winsys-egl-gdl-private.h"
#endif
#ifdef COGL_HAS_EGL_PLATFORM_ANDROID_SUPPORT
#include "cogl-winsys-egl-android-private.h"
#endif
#ifdef COGL_HAS_EGL_PLATFORM_POWERVR_NULL_SUPPORT
#include "cogl-winsys-egl-null-private.h"
#endif
cogl-renderer.c: Fix includes Only include cogl-xlib-renderer.h when XLIB support is available Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-09 07:19:26 +00:00
#if COGL_HAS_XLIB_SUPPORT
Remove inclusion of Xlib headers in Cogl headers Xlib headers define many trivially named objects which can later cause name collision problems when only cogl.h header is included in a program or library. Xlib headers are now only included through including the standalone header cogl-xlib.h. https://bugzilla.gnome.org/show_bug.cgi?id=661174 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-10-17 16:55:35 +00:00
#include "cogl-xlib-renderer.h"
cogl-renderer.c: Fix includes Only include cogl-xlib-renderer.h when XLIB support is available Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-09 07:19:26 +00:00
#endif
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
#ifdef COGL_HAS_GLX_SUPPORT
extern const CoglWinsysVtable *_cogl_winsys_glx_get_vtable (void);
#endif
Add a WGL winsys This adds a full winsys to handle WGL and Win32.
2011-05-09 16:48:50 +00:00
#ifdef COGL_HAS_WGL_SUPPORT
extern const CoglWinsysVtable *_cogl_winsys_wgl_get_vtable (void);
#endif
Update the SDL winsys The SDL winsys was missing a few minor features, such as the implementation. This patch adds that in. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-14 12:09:53 +00:00
#ifdef COGL_HAS_SDL_SUPPORT
extern const CoglWinsysVtable *_cogl_winsys_sdl_get_vtable (void);
#endif
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
typedef const CoglWinsysVtable *(*CoglWinsysVtableGetter) (void);
static CoglWinsysVtableGetter _cogl_winsys_vtable_getters[] =
{
#ifdef COGL_HAS_GLX_SUPPORT
_cogl_winsys_glx_get_vtable,
#endif
Rename the EGL_X11 winsys to EGL_XLIB Eventually we might want to have an XCB-based EGL winsys. We already have xlib-specific API in CoglRenderer (eg, to set a foreign display) so the application needs to be able to specifically select between XCB and XLIB. This also removes the POWERVR part while renaming COGL_HAS_EGL_PLATFORM_POWERVR_X11_SUPPORT to COGL_HAS_EGL_PLATFORM_XLIB_SUPPORT because the winsys is equally applicable to Mesa. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-13 16:23:25 +00:00
#ifdef COGL_HAS_EGL_PLATFORM_XLIB_SUPPORT
_cogl_winsys_egl_xlib_get_vtable,
Add a separate winsys vtable for each EGL platform Instead of just having an "EGL" renderer, there is now a separate winsys for each platform. Currently they just directly copy the vtable for the EGL platform so it is still only possible to have one EGL platform compiled into Cogl. However the intention is that the winsys-specific code for each platform will be moved into override functions in the corresponding platform winsys. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-08 17:24:40 +00:00
#endif
#ifdef COGL_HAS_EGL_PLATFORM_WAYLAND_SUPPORT
_cogl_winsys_egl_wayland_get_vtable,
#endif
#ifdef COGL_HAS_EGL_PLATFORM_KMS_SUPPORT
_cogl_winsys_egl_kms_get_vtable,
#endif
#ifdef COGL_HAS_EGL_PLATFORM_GDL_SUPPORT
_cogl_winsys_egl_gdl_get_vtable,
#endif
#ifdef COGL_HAS_EGL_PLATFORM_ANDROID_SUPPORT
_cogl_winsys_egl_android_get_vtable,
#endif
#ifdef COGL_HAS_EGL_PLATFORM_POWERVR_NULL_SUPPORT
_cogl_winsys_egl_null_get_vtable,
Add a WGL winsys This adds a full winsys to handle WGL and Win32.
2011-05-09 16:48:50 +00:00
#endif
#ifdef COGL_HAS_WGL_SUPPORT
_cogl_winsys_wgl_get_vtable,
Update the SDL winsys The SDL winsys was missing a few minor features, such as the implementation. This patch adds that in. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-14 12:09:53 +00:00
#endif
#ifdef COGL_HAS_SDL_SUPPORT
_cogl_winsys_sdl_get_vtable,
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
#endif
Make stub winsys into a proper winsys backend Instead of the stub winsys being a special case set of #ifdef'd code used when COGL_HAS_FULL_WINSYS wasn't defined, the stub winsys now implements a CoglWinsysVtable like all other winsys backends (it's just that everything is a NOP). This way we can get rid of the COGL_HAS_FULL_WINSYS define and also the stub winsys can be runtime selected whereas before it was incompatible with all other winsys backends.
2011-05-17 14:00:38 +00:00
_cogl_winsys_stub_get_vtable,
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
};
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
static void _cogl_renderer_free (CoglRenderer *renderer);
COGL_OBJECT_DEFINE (Renderer, renderer);
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
typedef struct _CoglNativeFilterClosure
{
CoglNativeFilterFunc func;
void *data;
} CoglNativeFilterClosure;
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
GQuark
cogl_renderer_error_quark (void)
{
return g_quark_from_static_string ("cogl-renderer-error-quark");
}
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
static const CoglWinsysVtable *
_cogl_renderer_get_winsys (CoglRenderer *renderer)
{
return renderer->winsys_vtable;
}
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
static void
native_filter_closure_free (CoglNativeFilterClosure *closure)
{
g_slice_free (CoglNativeFilterClosure, closure);
}
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
static void
_cogl_renderer_free (CoglRenderer *renderer)
{
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
const CoglWinsysVtable *winsys = _cogl_renderer_get_winsys (renderer);
winsys->renderer_disconnect (renderer);
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
#ifndef HAVE_DIRECTLY_LINKED_GL_LIBRARY
if (renderer->libgl_module)
g_module_close (renderer->libgl_module);
#endif
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
g_slist_foreach (renderer->event_filters,
(GFunc) native_filter_closure_free,
NULL);
g_slist_free (renderer->event_filters);
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
g_free (renderer);
}
CoglRenderer *
cogl_renderer_new (void)
{
CoglRenderer *renderer = g_new0 (CoglRenderer, 1);
Add internal _cogl_init() function This adds a _cogl_init function for Cogl that we expect to be the first thing called before anything else is done with Cogl. It's not a public API so it's expected that all entry points for Cogl that might be the first function used should call _cogl_init(). We currently call _cogl_init() in these functions: cogl_renderer_new cogl_display_new cogl_context_new cogl_android_set_native_window _cogl_init() can be called multiple times, and only the first call has any affect. For example _cogl_init() gives us a place check and parse the COGL_DEBUG environment variable. Since we don't have any need to parse command line arguments (we can always get user configuration options from the environment) our init function doesn't require argc/argv pointers. By saying up front that we aren't interested in command line arguments that means we can avoid the mess that is GOption based library initialization which is extremely fragile due to its lack of dependency tracking between modules. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-14 21:33:44 +00:00
_cogl_init ();
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
renderer->connected = FALSE;
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
renderer->event_filters = NULL;
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
xlib: Internally retrieve XEvents Previously we relied on the application to send all X events through Cogl using cogl_xlib_renderer_handle_event. This breaks the abstraction that an application shouldn't need to know what winsys Cogl is using. Now that we have main loop integreation in Cogl, the Xlib-based winsys's can report that Cogl needs to block on the file descriptor of the X connection and it can manually handle the events. The event retrieval can be disabled by an application if it calls the new cogl_xlib_renderer_set_event_retrieval_enabled() function. The event retrieval will also automatically be disabled if the application sets a foreign display. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-16 18:50:49 +00:00
#ifdef COGL_HAS_XLIB_SUPPORT
renderer->xlib_enable_event_retrieval = TRUE;
#endif
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
return _cogl_renderer_object_new (renderer);
}
#if COGL_HAS_XLIB_SUPPORT
void
work towards consistent platform file/symbol naming we've got into a bit of a mess with how we name platform specific symbols and files, so this is a first pass at trying to tidy that up. All platform specific symbols should be named like cogl_<platform>_symbol_name and similarly files should be named like cogl-<platform>-filename.c This patch tackles the X11 specific renderer/display APIs as a start. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-28 13:16:24 +00:00
cogl_xlib_renderer_set_foreign_display (CoglRenderer *renderer,
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
Display *xdisplay)
{
Start to reduce dependence on glib Since we've had several developers from admirable projects say they would like to use Cogl but would really prefer not to pull in gobject,gmodule and glib as extra dependencies we are investigating if we can get to the point where glib is only an optional dependency. Actually we feel like we only make minimal use of glib anyway, so it may well be quite straightforward to achieve this. This adds a --disable-glib configure option that can be used to disable features that depend on glib. Actually --disable-glib doesn't strictly disable glib at this point because it's more helpful if cogl continues to build as we make incremental progress towards this. The first use of glib that this patch tackles is the use of g_return_val_if_fail and g_return_if_fail which have been replaced with equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 21:34:30 +00:00
_COGL_RETURN_IF_FAIL (cogl_is_renderer (renderer));
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
/* NB: Renderers are considered immutable once connected */
Start to reduce dependence on glib Since we've had several developers from admirable projects say they would like to use Cogl but would really prefer not to pull in gobject,gmodule and glib as extra dependencies we are investigating if we can get to the point where glib is only an optional dependency. Actually we feel like we only make minimal use of glib anyway, so it may well be quite straightforward to achieve this. This adds a --disable-glib configure option that can be used to disable features that depend on glib. Actually --disable-glib doesn't strictly disable glib at this point because it's more helpful if cogl continues to build as we make incremental progress towards this. The first use of glib that this patch tackles is the use of g_return_val_if_fail and g_return_if_fail which have been replaced with equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 21:34:30 +00:00
_COGL_RETURN_IF_FAIL (!renderer->connected);
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
renderer->foreign_xdpy = xdisplay;
xlib: Internally retrieve XEvents Previously we relied on the application to send all X events through Cogl using cogl_xlib_renderer_handle_event. This breaks the abstraction that an application shouldn't need to know what winsys Cogl is using. Now that we have main loop integreation in Cogl, the Xlib-based winsys's can report that Cogl needs to block on the file descriptor of the X connection and it can manually handle the events. The event retrieval can be disabled by an application if it calls the new cogl_xlib_renderer_set_event_retrieval_enabled() function. The event retrieval will also automatically be disabled if the application sets a foreign display. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-16 18:50:49 +00:00
/* If the application is using a foreign display then we can assume
it will also do its own event retrieval */
cogl_xlib_renderer_set_event_retrieval_enabled (renderer, FALSE);
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
}
Display *
work towards consistent platform file/symbol naming we've got into a bit of a mess with how we name platform specific symbols and files, so this is a first pass at trying to tidy that up. All platform specific symbols should be named like cogl_<platform>_symbol_name and similarly files should be named like cogl-<platform>-filename.c This patch tackles the X11 specific renderer/display APIs as a start. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-28 13:16:24 +00:00
cogl_xlib_renderer_get_foreign_display (CoglRenderer *renderer)
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
{
Start to reduce dependence on glib Since we've had several developers from admirable projects say they would like to use Cogl but would really prefer not to pull in gobject,gmodule and glib as extra dependencies we are investigating if we can get to the point where glib is only an optional dependency. Actually we feel like we only make minimal use of glib anyway, so it may well be quite straightforward to achieve this. This adds a --disable-glib configure option that can be used to disable features that depend on glib. Actually --disable-glib doesn't strictly disable glib at this point because it's more helpful if cogl continues to build as we make incremental progress towards this. The first use of glib that this patch tackles is the use of g_return_val_if_fail and g_return_if_fail which have been replaced with equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 21:34:30 +00:00
_COGL_RETURN_VAL_IF_FAIL (cogl_is_renderer (renderer), NULL);
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
return renderer->foreign_xdpy;
}
xlib: Internally retrieve XEvents Previously we relied on the application to send all X events through Cogl using cogl_xlib_renderer_handle_event. This breaks the abstraction that an application shouldn't need to know what winsys Cogl is using. Now that we have main loop integreation in Cogl, the Xlib-based winsys's can report that Cogl needs to block on the file descriptor of the X connection and it can manually handle the events. The event retrieval can be disabled by an application if it calls the new cogl_xlib_renderer_set_event_retrieval_enabled() function. The event retrieval will also automatically be disabled if the application sets a foreign display. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-12-16 18:50:49 +00:00
void
cogl_xlib_renderer_set_event_retrieval_enabled (CoglRenderer *renderer,
gboolean enable)
{
_COGL_RETURN_IF_FAIL (cogl_is_renderer (renderer));
/* NB: Renderers are considered immutable once connected */
_COGL_RETURN_IF_FAIL (!renderer->connected);
renderer->xlib_enable_event_retrieval = enable;
}
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
#endif /* COGL_HAS_XLIB_SUPPORT */
gboolean
cogl_renderer_check_onscreen_template (CoglRenderer *renderer,
CoglOnscreenTemplate *onscreen_template,
GError **error)
{
Moves all GLX code down from Clutter to Cogl This migrates all the GLX window system code down from the Clutter backend code into a Cogl winsys. Moving OpenGL window system binding code down from Clutter into Cogl is the biggest blocker to having Cogl become a standalone 3D graphics library, so this is an important step in that direction.
2010-11-05 12:28:33 +00:00
CoglDisplay *display;
renderer: don't re-connect for display check This ensure that cogl_renderer_check_onscreen_template() doesn't call winsys->renderer_connect() if the renderer has already been connected as that can fail with some backends. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-12-05 19:11:52 +00:00
if (!cogl_renderer_connect (renderer, error))
Moves all GLX code down from Clutter to Cogl This migrates all the GLX window system code down from the Clutter backend code into a Cogl winsys. Moving OpenGL window system binding code down from Clutter into Cogl is the biggest blocker to having Cogl become a standalone 3D graphics library, so this is an important step in that direction.
2010-11-05 12:28:33 +00:00
return FALSE;
display = cogl_display_new (renderer, onscreen_template);
if (!cogl_display_setup (display, error))
{
cogl_object_unref (display);
return FALSE;
}
cogl_object_unref (display);
Make stub winsys into a proper winsys backend Instead of the stub winsys being a special case set of #ifdef'd code used when COGL_HAS_FULL_WINSYS wasn't defined, the stub winsys now implements a CoglWinsysVtable like all other winsys backends (it's just that everything is a NOP). This way we can get rid of the COGL_HAS_FULL_WINSYS define and also the stub winsys can be runtime selected whereas before it was incompatible with all other winsys backends.
2011-05-17 14:00:38 +00:00
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
return TRUE;
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
static gboolean
_cogl_renderer_choose_driver (CoglRenderer *renderer,
GError **error)
{
const char *driver_name = g_getenv ("COGL_DRIVER");
const char *libgl_name;
cogl: Add support for reading a cogl.conf config file When cogl initializes we now check for a cogl/cogl.conf in any of the system config dirs (determined using $XDG_CONFIG_DIRS on linux) we then also check the user's config directory (determined using XDG_CONFIG_HOME on linux) for a cogl/cogl.conf file. Options specified in the user config file have priority over the system config options. The config file has an .ini style syntax with a mandatory [global] section and we currently understand 3 keynames: COGL_DEBUG, COGL_DRIVER and COGL_RENDERER which have the same semantics as the corresponding environment variables. Options set using the environment variables have priority over options set in the config files. To allow users to undo the enabling of debug options in config files this patch also adds a check for COGL_NO_DEBUG environment variable which will disable the specified options which may have been enabled in config files. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-03 17:15:54 +00:00
if (!driver_name)
driver_name = _cogl_config_driver;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
#ifdef HAVE_COGL_GL
renderer: Make COGL_RENDERER / COGL_DRIVER env. variables case insensitive This will make it much more user friendly :-) Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-12-09 17:13:17 +00:00
if (driver_name == NULL || !g_ascii_strcasecmp (driver_name, "gl"))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
{
renderer->driver = COGL_DRIVER_GL;
libgl_name = COGL_GL_LIBNAME;
goto found;
}
#endif
#ifdef HAVE_COGL_GLES2
renderer: Make COGL_RENDERER / COGL_DRIVER env. variables case insensitive This will make it much more user friendly :-) Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-12-09 17:13:17 +00:00
if (driver_name == NULL || !g_ascii_strcasecmp (driver_name, "gles2"))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
{
renderer->driver = COGL_DRIVER_GLES2;
libgl_name = COGL_GLES2_LIBNAME;
goto found;
}
#endif
#ifdef HAVE_COGL_GLES
renderer: Make COGL_RENDERER / COGL_DRIVER env. variables case insensitive This will make it much more user friendly :-) Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-12-09 17:13:17 +00:00
if (driver_name == NULL || !g_ascii_strcasecmp (driver_name, "gles1"))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
{
renderer->driver = COGL_DRIVER_GLES1;
libgl_name = COGL_GLES1_LIBNAME;
goto found;
}
#endif
g_set_error (error,
COGL_DRIVER_ERROR,
COGL_DRIVER_ERROR_NO_SUITABLE_DRIVER_FOUND,
"No suitable driver found");
return FALSE;
found:
#ifndef HAVE_DIRECTLY_LINKED_GL_LIBRARY
Specify the full filename when g_module_open'ing the GL library Instead of using g_module_build_path with the short name of the GL library (eg, "GL") and relying on glib to add the suffix and prefix, the configure script now directly encodes the full name including the version number (eg, "libGL.so.1"). This is necessary because distros don't always install the non-versioned suffix for the library. The GLES libraries are left without the version suffix because it's not clear what should be placed here and I can't find any documentation from Khronos to clarify this. Mesa seems to install a file called libGLESv2.so.2 but the IMG SDK doesn't install any versioned library. There is an example of dynamically loading libGLESv2 in the Chromium source code and that does not use the version suffix even though it does use the version suffix for GL. This implies that it's at least fairly normal to load the unversioned name for GLES. https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 17:07:06 +00:00
renderer->libgl_module = g_module_open (libgl_name,
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
G_MODULE_BIND_LAZY);
if (renderer->libgl_module == NULL)
{
g_set_error (error, COGL_DRIVER_ERROR,
COGL_DRIVER_ERROR_FAILED_TO_LOAD_LIBRARY,
"Failed to dynamically open the GL library \"%s\"",
libgl_name);
return FALSE;
}
#endif /* HAVE_DIRECTLY_LINKED_GL_LIBRARY */
return TRUE;
}
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
/* Final connection API */
gboolean
cogl_renderer_connect (CoglRenderer *renderer, GError **error)
{
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
int i;
GString *error_message;
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
if (renderer->connected)
return TRUE;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
/* The driver needs to be chosen before connecting the renderer
because eglInitialize requires the library containing the GL API
to be loaded before its called */
if (!_cogl_renderer_choose_driver (renderer, error))
return FALSE;
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
error_message = g_string_new ("");
for (i = 0; i < G_N_ELEMENTS (_cogl_winsys_vtable_getters); i++)
{
const CoglWinsysVtable *winsys = _cogl_winsys_vtable_getters[i]();
GError *tmp_error = NULL;
winsys: Expose environment variable to choose winsys This makes it possible to override the winsys that cogl uses by setting the COGL_RENDERER environment variable e.g. to "GLX" or "EGL"
2011-04-18 15:24:51 +00:00
renderer: Expose winsys ID setter/getters This adds API to let you override the choice of Cogl's winsys backend. Previously it was only possible to override the winsys using the COGL_RENDERER environment variable, but it's useful for something like Clutter to be able to control the winsys via API without needing environment variable tricks. This also adds API to query back the winsys chosen by Cogl, in case you don't set an explicit override. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-20 12:29:12 +00:00
if (renderer->winsys_id_override != COGL_WINSYS_ID_ANY)
{
if (renderer->winsys_id_override != winsys->id)
continue;
}
else
{
char *user_choice = getenv ("COGL_RENDERER");
cogl: Add support for reading a cogl.conf config file When cogl initializes we now check for a cogl/cogl.conf in any of the system config dirs (determined using $XDG_CONFIG_DIRS on linux) we then also check the user's config directory (determined using XDG_CONFIG_HOME on linux) for a cogl/cogl.conf file. Options specified in the user config file have priority over the system config options. The config file has an .ini style syntax with a mandatory [global] section and we currently understand 3 keynames: COGL_DEBUG, COGL_DRIVER and COGL_RENDERER which have the same semantics as the corresponding environment variables. Options set using the environment variables have priority over options set in the config files. To allow users to undo the enabling of debug options in config files this patch also adds a check for COGL_NO_DEBUG environment variable which will disable the specified options which may have been enabled in config files. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-03 17:15:54 +00:00
if (!user_choice)
user_choice = _cogl_config_renderer;
renderer: Make COGL_RENDERER / COGL_DRIVER env. variables case insensitive This will make it much more user friendly :-) Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-12-09 17:13:17 +00:00
if (user_choice &&
g_ascii_strcasecmp (winsys->name, user_choice) != 0)
renderer: Expose winsys ID setter/getters This adds API to let you override the choice of Cogl's winsys backend. Previously it was only possible to override the winsys using the COGL_RENDERER environment variable, but it's useful for something like Clutter to be able to control the winsys via API without needing environment variable tricks. This also adds API to query back the winsys chosen by Cogl, in case you don't set an explicit override. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-20 12:29:12 +00:00
continue;
}
winsys: Expose environment variable to choose winsys This makes it possible to override the winsys that cogl uses by setting the COGL_RENDERER environment variable e.g. to "GLX" or "EGL"
2011-04-18 15:24:51 +00:00
renderer: set winsys on renderer before ->renderer_connect When iterating through all the possible window systems trying to find one we can successfully connect we now associated the current winsys vtable with the renderer before calling winsys->renderer_connect in case the implementation calls some other Cogl API that expects to be able to determine the current winsys. For example calling _cogl_get_proc_address when querying winsys extensions as part of a successful connect will need to get at the current winsys vtable.
2011-05-25 00:49:44 +00:00
/* At least temporarily we will associate this winsys with
* the renderer in-case ->renderer_connect calls API that
* wants to query the current winsys... */
renderer->winsys_vtable = winsys;
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
if (!winsys->renderer_connect (renderer, &tmp_error))
{
g_string_append_c (error_message, '\n');
g_string_append (error_message, tmp_error->message);
g_error_free (tmp_error);
}
else
{
renderer->connected = TRUE;
g_string_free (error_message, TRUE);
return TRUE;
}
}
Moves all GLX code down from Clutter to Cogl This migrates all the GLX window system code down from the Clutter backend code into a Cogl winsys. Moving OpenGL window system binding code down from Clutter into Cogl is the biggest blocker to having Cogl become a standalone 3D graphics library, so this is an important step in that direction.
2010-11-05 12:28:33 +00:00
Add a vtable of indirection to the winsys code So that we can dynamically select what winsys backend to use at runtime we need to have some indirection to how code accesses the winsys instead of simply calling _cogl_winsys* functions that would collide if we wanted to compile more than one backend into Cogl.
2011-02-25 11:29:08 +00:00
if (!renderer->connected)
{
renderer->winsys_vtable = NULL;
g_set_error (error, COGL_WINSYS_ERROR,
COGL_WINSYS_ERROR_INIT,
"Failed to connected to any renderer: %s",
error_message->str);
g_string_free (error_message, TRUE);
return FALSE;
}
return TRUE;
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 17:06:50 +00:00
}
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
CoglFilterReturn
replace public native_event APIs with typesafe APIs This adds Xlib and Win32 typesafe replacements for cogl_renderer_handle_native_event, cogl_renderer_add_native_filter, cogl_renderer_remove_native_filter. The old functions are kept as an implementation detail so we can share code. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-28 12:38:50 +00:00
_cogl_renderer_handle_native_event (CoglRenderer *renderer,
void *event)
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
{
GSList *l, *next;
/* Pass the event on to all of the registered filters in turn */
for (l = renderer->event_filters; l; l = next)
{
CoglNativeFilterClosure *closure = l->data;
/* The next pointer is taken now so that we can handle the
closure being removed during emission */
next = l->next;
if (closure->func (event, closure->data) == COGL_FILTER_REMOVE)
return COGL_FILTER_REMOVE;
}
/* If the backend for the renderer also wants to see the events, it
should just register its own filter */
return COGL_FILTER_CONTINUE;
}
void
replace public native_event APIs with typesafe APIs This adds Xlib and Win32 typesafe replacements for cogl_renderer_handle_native_event, cogl_renderer_add_native_filter, cogl_renderer_remove_native_filter. The old functions are kept as an implementation detail so we can share code. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-28 12:38:50 +00:00
_cogl_renderer_add_native_filter (CoglRenderer *renderer,
CoglNativeFilterFunc func,
void *data)
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
{
CoglNativeFilterClosure *closure;
closure = g_slice_new (CoglNativeFilterClosure);
closure->func = func;
closure->data = data;
renderer->event_filters = g_slist_prepend (renderer->event_filters, closure);
}
void
replace public native_event APIs with typesafe APIs This adds Xlib and Win32 typesafe replacements for cogl_renderer_handle_native_event, cogl_renderer_add_native_filter, cogl_renderer_remove_native_filter. The old functions are kept as an implementation detail so we can share code. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-28 12:38:50 +00:00
_cogl_renderer_remove_native_filter (CoglRenderer *renderer,
CoglNativeFilterFunc func,
void *data)
cogl-renderer: Move the XEvent filters to be generic for all renderers Instead of having cogl_renderer_xlib_add_filter and friends there is now cogl_renderer_add_native_filter which can be used regardless of the backend. The callback function for the filter now just takes a void pointer instead of an XEvent pointer which should be interpreted differently depending on the backend. For example, on Xlib it would still be an XEvent but on Windows it could be a MSG. This simplifies the code somewhat because the _cogl_xlib_add_filter no longer needs to have its own filter list when a stub renderer is used because there is always a renderer available. cogl_renderer_xlib_handle_event has also been renamed to cogl_renderer_handle_native_event. This just forwards the event on to all of the listeners. The backend renderer is expected to register its own event filter if it wants to process the events in some way.
2011-04-13 15:41:41 +00:00
{
GSList *l, *prev = NULL;
for (l = renderer->event_filters; l; prev = l, l = l->next)
{
CoglNativeFilterClosure *closure = l->data;
if (closure->func == func && closure->data == data)
{
native_filter_closure_free (closure);
if (prev)
prev->next = g_slist_delete_link (prev->next, l);
else
renderer->event_filters =
g_slist_delete_link (renderer->event_filters, l);
break;
}
}
}
renderer: Expose winsys ID setter/getters This adds API to let you override the choice of Cogl's winsys backend. Previously it was only possible to override the winsys using the COGL_RENDERER environment variable, but it's useful for something like Clutter to be able to control the winsys via API without needing environment variable tricks. This also adds API to query back the winsys chosen by Cogl, in case you don't set an explicit override. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-20 12:29:12 +00:00
void
cogl_renderer_set_winsys_id (CoglRenderer *renderer,
CoglWinsysID winsys_id)
{
Start to reduce dependence on glib Since we've had several developers from admirable projects say they would like to use Cogl but would really prefer not to pull in gobject,gmodule and glib as extra dependencies we are investigating if we can get to the point where glib is only an optional dependency. Actually we feel like we only make minimal use of glib anyway, so it may well be quite straightforward to achieve this. This adds a --disable-glib configure option that can be used to disable features that depend on glib. Actually --disable-glib doesn't strictly disable glib at this point because it's more helpful if cogl continues to build as we make incremental progress towards this. The first use of glib that this patch tackles is the use of g_return_val_if_fail and g_return_if_fail which have been replaced with equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 21:34:30 +00:00
_COGL_RETURN_IF_FAIL (!renderer->connected);
renderer: Expose winsys ID setter/getters This adds API to let you override the choice of Cogl's winsys backend. Previously it was only possible to override the winsys using the COGL_RENDERER environment variable, but it's useful for something like Clutter to be able to control the winsys via API without needing environment variable tricks. This also adds API to query back the winsys chosen by Cogl, in case you don't set an explicit override. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-20 12:29:12 +00:00
renderer->winsys_id_override = winsys_id;
}
CoglWinsysID
cogl_renderer_get_winsys_id (CoglRenderer *renderer)
{
Start to reduce dependence on glib Since we've had several developers from admirable projects say they would like to use Cogl but would really prefer not to pull in gobject,gmodule and glib as extra dependencies we are investigating if we can get to the point where glib is only an optional dependency. Actually we feel like we only make minimal use of glib anyway, so it may well be quite straightforward to achieve this. This adds a --disable-glib configure option that can be used to disable features that depend on glib. Actually --disable-glib doesn't strictly disable glib at this point because it's more helpful if cogl continues to build as we make incremental progress towards this. The first use of glib that this patch tackles is the use of g_return_val_if_fail and g_return_if_fail which have been replaced with equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 21:34:30 +00:00
_COGL_RETURN_VAL_IF_FAIL (renderer->connected, 0);
renderer: Expose winsys ID setter/getters This adds API to let you override the choice of Cogl's winsys backend. Previously it was only possible to override the winsys using the COGL_RENDERER environment variable, but it's useful for something like Clutter to be able to control the winsys via API without needing environment variable tricks. This also adds API to query back the winsys chosen by Cogl, in case you don't set an explicit override. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-20 12:29:12 +00:00
return renderer->winsys_vtable->id;
}
Don't use the 'NULL' GModule to resolve GL symbols Previously, _cogl_get_proc_address had a fallback to resolve the symbol using g_module_open(NULL) to get the symbol from anywhere in the address space. The EGL backend ends up using this on some drivers because eglGetProcAddress isn't meant to return a pointer for core functions. This causes problems if something in the process is linking against a different GL library, for example Cairo may be linking against libGL itself. In this case it may end up resolving symbols from the GL library even if GLES is being used. This patch removes the fallback. The EGL version now has its own fallback instead which passes the existing libgl_module from the renderer to g_module_symbol so that it should only get symbols from that library or its dependency chain. The GLX and WGL winsys only call glXGetProcAddress and wglGetProcAddress. The stub winsys does however continue using the global symbol lookup. The internal _cogl_get_proc_address function has been renamed to _cogl_renderer_get_proc_address because it needs a connected renderer to work so it could be considered to be a renderer method. The pointer to the renderer is passed down to the winsys backends so that it can use the data attached to the renderer to get the module pointers. https://bugzilla.gnome.org/show_bug.cgi?id=655412 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-07-27 11:30:02 +00:00
void *
_cogl_renderer_get_proc_address (CoglRenderer *renderer,
const char *name)
{
const CoglWinsysVtable *winsys = _cogl_renderer_get_winsys (renderer);
return winsys->renderer_get_proc_address (renderer, name);
}
renderer: Add cogl_renderer_get_n_fragment_texture_units() Add a method on the renderer to know how many texture image units are accessible from fragment shaders. https://bugzilla.gnome.org/show_bug.cgi?id=657347 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-08-25 16:26:44 +00:00
int
cogl_renderer_get_n_fragment_texture_units (CoglRenderer *renderer)
{
int n = 0;
_COGL_GET_CONTEXT (ctx, 0);
#if defined (HAVE_COGL_GL) || defined (HAVE_COGL_GLES2)
if (ctx->driver == COGL_DRIVER_GL || ctx->driver == COGL_DRIVER_GLES2)
GE (ctx, glGetIntegerv (GL_MAX_TEXTURE_IMAGE_UNITS, &n));
#endif
return n;
}
Reference in New Issue Copy Permalink