isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-22 16:10:41 -05:00
Code Issues Packages Projects Releases Wiki Activity
b21de497d1
mutter/cogl/cogl-renderer.c

876 lines
23 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 12:06:50 -05:00
/*
* Cogl
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-21 20:28:54 -05:00
* A Low Level GPU Graphics and Utilities API
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 12:06:50 -05:00
*
* Copyright (C) 2011 Intel Corporation.
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-21 20:28:54 -05:00
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use, copy,
* modify, merge, publish, distribute, sublicense, and/or sell copies
* of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
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 12:06:50 -05:00
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-21 20:28:54 -05:00
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
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 12:06:50 -05:00
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-21 20:28:54 -05:00
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
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 12:06:50 -05:00
*
* 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 11:24:51 -04:00
#include <stdlib.h>
#include <string.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 17:34:30 -04:00
#include "cogl-util.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 17:33:44 -04: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 12:06:50 -05: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 12:26:44 -04:00
#include "cogl-context-private.h"
Remove cogl-internal.h This remove cogl-internal.h in favour of using cogl-private.h. Some things in cogl-internal.h were moved to driver/gl/cogl-util-gl-private.h and the _cogl_gl_error_to_string function whose prototype was moved from cogl-internal.h to cogl-util-gl-private.h has had its implementation moved from cogl.c to cogl-util-gl.c Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 01cc82ece091aa3bec4c07fdd6bc9e5135fca573)
2013-01-20 13:47:40 -05:00
#include "cogl-util-gl-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 12:06:50 -05: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 10:00:38 -04: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 13:15:54 -04:00
#include "cogl-config-private.h"
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
#include "cogl-error-private.h"
Registers gtypes for all public objects and structs This adds much more comprehensive support for gobject-introspection based bindings by registering all objects as fundamental types that inherit from CoglObject, and all structs as boxed types. Co-Author: Robert Bragg <robert@linux.intel.com> Reviewed-by: Neil Roberts <neil@linux.intel.com>
2013-09-02 11:02:42 -04:00
#include "cogl-gtype-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 02:19:26 -05: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 11:23:25 -05: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 12:24:40 -05: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
cogl: add Mir EGL platform
2014-11-17 09:49:20 -05:00
#ifdef COGL_HAS_EGL_PLATFORM_MIR_SUPPORT
#include "cogl-winsys-egl-mir-private.h"
#endif
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 12:24:40 -05:00
#ifdef COGL_HAS_EGL_PLATFORM_POWERVR_NULL_SUPPORT
#include "cogl-winsys-egl-null-private.h"
#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 06:29:08 -05:00
#ifdef COGL_HAS_GLX_SUPPORT
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 13:21:28 -05:00
#include "cogl-winsys-glx-private.h"
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 06:29:08 -05:00
#endif
Add a WGL winsys This adds a full winsys to handle WGL and Win32.
2011-05-09 12:48:50 -04:00
#ifdef COGL_HAS_WGL_SUPPORT
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 13:21:28 -05:00
#include "cogl-winsys-wgl-private.h"
Add a WGL winsys This adds a full winsys to handle WGL and Win32.
2011-05-09 12:48:50 -04:00
#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 07:09:53 -05:00
#ifdef COGL_HAS_SDL_SUPPORT
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 13:21:28 -05:00
#include "cogl-winsys-sdl-private.h"
#endif
Don't use #if with defines that are either defined or not COGL_HAS_* and COGL_ENABLE_DEBUG are either defined in config.h or not. So let's test against this, not against their truth value, this allow us to use -Wundef to catch undefined macros in preprocessor directives. (cherry picked from commit 73b62832f24711073b0876a6c0f5c61727842c1c)
2012-12-28 21:00:00 -05:00
#ifdef COGL_HAS_XLIB_SUPPORT
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 13:21:28 -05:00
#include "cogl-xlib-renderer.h"
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 07:09:53 -05: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 06:29:08 -05:00
typedef const CoglWinsysVtable *(*CoglWinsysVtableGetter) (void);
framebuffer: split GL code out from cogl-framebuffer.c This splits out most of the OpenGL specific code from cogl-framebuffer.c into cogl-framebuffer-gl.c and extends the CoglDriverVtable interface for cogl-framebuffer.c to use. There are hopes to support several different backends for Cogl eventually to hopefully get us closer to the metal so this makes some progress in organizing which parts of Cogl are OpenGL specific so these parts can potentially be switched out later. The only remaining use of OpenGL still in cogl-framebuffer.c is to handle cogl_framebuffer_read_pixels.
2012-08-31 19:04:00 -04:00
#ifdef HAVE_COGL_GL
extern const CoglTextureDriver _cogl_texture_driver_gl;
extern const CoglDriverVtable _cogl_driver_gl;
#endif
#if defined (HAVE_COGL_GLES) || defined (HAVE_COGL_GLES2)
extern const CoglTextureDriver _cogl_texture_driver_gles;
extern const CoglDriverVtable _cogl_driver_gles;
#endif
Adds a NOP driver This adds a new "nop" driver that does nothing. This can be selected at runtime either with the COGL_DRIVER=nop environment variable or by passing COGL_DRIVER_NOP to cogl_renderer_set_driver() Adding the nop driver gives us a way to test workloads without any driver and hardware overheads which can help us understand how Cogl's state tracking performs in isolation. Having a nop driver can also serve as an shell/outline for creating other drivers later. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 90587418233b6438290741d80aedf193ae660cad)
2012-09-12 17:39:46 -04:00
extern const CoglDriverVtable _cogl_driver_nop;
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
typedef struct _CoglDriverDescription
{
CoglDriver id;
const char *name;
CoglRendererConstraint constraints;
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
/* It would be nice to make this a pointer and then use a compound
* literal from C99 to initialise it but we probably can't get away
* with using C99 here. Instead we'll just use a fixed-size array.
* GCC should complain if someone adds an 8th feature to a
* driver. */
const CoglPrivateFeature private_features[8];
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
const CoglDriverVtable *vtable;
const CoglTextureDriver *texture_driver;
const char *libgl_name;
} CoglDriverDescription;
static CoglDriverDescription _cogl_drivers[] =
{
#ifdef HAVE_COGL_GL
{
COGL_DRIVER_GL,
"gl",
0,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
{ COGL_PRIVATE_FEATURE_ANY_GL,
COGL_PRIVATE_FEATURE_GL_FIXED,
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
COGL_PRIVATE_FEATURE_GL_PROGRAMMABLE,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
-1 },
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
&_cogl_driver_gl,
&_cogl_texture_driver_gl,
COGL_GL_LIBNAME,
},
{
COGL_DRIVER_GL3,
"gl3",
0,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
{ COGL_PRIVATE_FEATURE_ANY_GL,
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
COGL_PRIVATE_FEATURE_GL_PROGRAMMABLE,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
-1 },
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
&_cogl_driver_gl,
&_cogl_texture_driver_gl,
COGL_GL_LIBNAME,
},
#endif
#ifdef HAVE_COGL_GLES2
{
COGL_DRIVER_GLES2,
"gles2",
COGL_RENDERER_CONSTRAINT_SUPPORTS_COGL_GLES2,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
{ COGL_PRIVATE_FEATURE_ANY_GL,
COGL_PRIVATE_FEATURE_GL_EMBEDDED,
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
COGL_PRIVATE_FEATURE_GL_PROGRAMMABLE,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
-1 },
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
&_cogl_driver_gles,
&_cogl_texture_driver_gles,
COGL_GLES2_LIBNAME,
},
#endif
#ifdef HAVE_COGL_GLES
{
COGL_DRIVER_GLES1,
"gles1",
0,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
{ COGL_PRIVATE_FEATURE_ANY_GL,
COGL_PRIVATE_FEATURE_GL_EMBEDDED,
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
COGL_PRIVATE_FEATURE_GL_FIXED,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
-1 },
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
&_cogl_driver_gles,
&_cogl_texture_driver_gles,
COGL_GLES1_LIBNAME,
},
Adds "webgl" driver This adds a COGL_DRIVER_WEBGL enum and a new driver description for webgl in cogl-renderer.c. This also adds a COGL_DRIVER_FLAG_OPENGL_WEB driver flag and a HAVE_COGL_WEBGL define which we can start to use to handle special cases where webgl differs from gles2. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 2c167b7a4ee56241827322bbe7cb287b0628437c)
2013-05-11 15:02:43 -04:00
#endif
#ifdef USING_EMSCRIPTEN
{
COGL_DRIVER_WEBGL,
"webgl",
0,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
{ COGL_PRIVATE_FEATURE_ANY_GL,
COGL_PRIVATE_FEATURE_GL_EMBEDDED,
COGL_PRIVATE_FEATURE_GL_PROGRAMMABLE,
Adds "webgl" driver This adds a COGL_DRIVER_WEBGL enum and a new driver description for webgl in cogl-renderer.c. This also adds a COGL_DRIVER_FLAG_OPENGL_WEB driver flag and a HAVE_COGL_WEBGL define which we can start to use to handle special cases where webgl differs from gles2. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 2c167b7a4ee56241827322bbe7cb287b0628437c)
2013-05-11 15:02:43 -04:00
COGL_PRIVATE_FEATURE_GL_WEB,
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
-1 },
Adds "webgl" driver This adds a COGL_DRIVER_WEBGL enum and a new driver description for webgl in cogl-renderer.c. This also adds a COGL_DRIVER_FLAG_OPENGL_WEB driver flag and a HAVE_COGL_WEBGL define which we can start to use to handle special cases where webgl differs from gles2. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 2c167b7a4ee56241827322bbe7cb287b0628437c)
2013-05-11 15:02:43 -04:00
&_cogl_driver_gles,
&_cogl_texture_driver_gles,
NULL,
},
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
#endif
{
COGL_DRIVER_NOP,
"nop",
0, /* constraints satisfied */
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
{ -1 },
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
&_cogl_driver_nop,
NULL, /* texture driver */
NULL /* libgl_name */
}
};
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 06:29:08 -05:00
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 11:23:25 -05: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 12:24:40 -05: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
cogl: add Mir EGL platform
2014-11-17 09:49:20 -05:00
#ifdef COGL_HAS_EGL_PLATFORM_MIR_SUPPORT
_cogl_winsys_egl_mir_get_vtable,
#endif
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 12:24:40 -05:00
#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 12:48:50 -04: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 07:09:53 -05: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 06:29:08 -05: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 10:00:38 -04: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 06:29:08 -05: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 12:06:50 -05:00
static void _cogl_renderer_free (CoglRenderer *renderer);
COGL_OBJECT_DEFINE (Renderer, renderer);
Registers gtypes for all public objects and structs This adds much more comprehensive support for gobject-introspection based bindings by registering all objects as fundamental types that inherit from CoglObject, and all structs as boxed types. Co-Author: Robert Bragg <robert@linux.intel.com> Reviewed-by: Neil Roberts <neil@linux.intel.com>
2013-09-02 11:02:42 -04:00
COGL_GTYPE_DEFINE_CLASS (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 12:06:50 -05: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 11:41:41 -04:00
typedef struct _CoglNativeFilterClosure
{
CoglNativeFilterFunc func;
void *data;
} CoglNativeFilterClosure;
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
uint32_t
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 12:06:50 -05:00
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 06:29:08 -05: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 11:41:41 -04: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 12:06:50 -05: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 06:29:08 -05:00
const CoglWinsysVtable *winsys = _cogl_renderer_get_winsys (renderer);
kms: Add mirror support and env var configurability This adds support for mirroring the display output on two KMS connectors. This patch also checks for a number of environment variables that can influence how KMS is configured. The following variables can be set: COGL_KMS_MIRROR: If this is set to anything then Cogl will try and setup two connectors with the same resolution so that onscreen frame buffers can be mirrored. COGL_KMS_CONNECTOR0: This can be set to an integer identifier for a specific KMS connector id to use for the first output. COGL_KMS_CONNECTOR0_MODE: Can be set to a mode name like "1024x768" explicitly select what mode should be used for the first output. If COGL_KMS_MIRROR is set then COGL_KMS_CONNECTOR1 and COGL_KMS_CONNECTOR1_MODE can optionally be set to specify a connector id and mode name for the second output. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-25 14:29:29 -05:00
Add api for queuing idle callback internally This adds a _cogl_poll_renderer_add_idle api that can be used internally for queuing an idle callback without needing to make any assumption about the system mainloop that is being used. This is now used to avoid having the _cogl_poll_renderer_dispatch() directly check for all kinds of events to dispatch, and to avoid having the winsys dispatch vfuncs need to directly know about CoglContext. This means we can now avoid having a back reference from CoglRenderer to the CoglContext. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit a1e169f18f4257caec58760adccfe4ec09b9805d)
2013-04-18 09:19:43 -04:00
_cogl_closure_list_disconnect_all (&renderer->idle_closures);
kms: Add mirror support and env var configurability This adds support for mirroring the display output on two KMS connectors. This patch also checks for a number of environment variables that can influence how KMS is configured. The following variables can be set: COGL_KMS_MIRROR: If this is set to anything then Cogl will try and setup two connectors with the same resolution so that onscreen frame buffers can be mirrored. COGL_KMS_CONNECTOR0: This can be set to an integer identifier for a specific KMS connector id to use for the first output. COGL_KMS_CONNECTOR0_MODE: Can be set to a mode name like "1024x768" explicitly select what mode should be used for the first output. If COGL_KMS_MIRROR is set then COGL_KMS_CONNECTOR1 and COGL_KMS_CONNECTOR1_MODE can optionally be set to specify a connector id and mode name for the second output. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-25 14:29:29 -05:00
if (winsys)
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 11:41:41 -04: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 15:44:56 -04: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 11:41:41 -04:00
g_slist_foreach (renderer->event_filters,
(GFunc) native_filter_closure_free,
NULL);
g_slist_free (renderer->event_filters);
Move event polling into CoglRenderer This updates the cogl_poll_ apis to allow dispatching events before we have a CoglContext and to also enables pollfd state to be changed in a more add-hoc way by different Cogl components by replacing the winsys->get_poll_info with _cogl_poll_renderer_add/remove_fd functions and a winsys->get_dispatch_timeout vfunc. One of the intentions here is that applications should be able to run their mainloop before creating a CoglContext to potentially get events relating to CoglOutputs. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 667e58c9cb2662aef5f44e580a9eda42dc8d0176)
2013-04-16 18:46:03 -04:00
g_array_free (renderer->poll_fds, 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 12:06:50 -05: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 17:33:44 -04: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 12:06:50 -05: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 11:41:41 -04: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 12:06:50 -05:00
Move event polling into CoglRenderer This updates the cogl_poll_ apis to allow dispatching events before we have a CoglContext and to also enables pollfd state to be changed in a more add-hoc way by different Cogl components by replacing the winsys->get_poll_info with _cogl_poll_renderer_add/remove_fd functions and a winsys->get_dispatch_timeout vfunc. One of the intentions here is that applications should be able to run their mainloop before creating a CoglContext to potentially get events relating to CoglOutputs. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 667e58c9cb2662aef5f44e580a9eda42dc8d0176)
2013-04-16 18:46:03 -04:00
renderer->poll_fds = g_array_new (FALSE, TRUE, sizeof (CoglPollFD));
Use the Wayland embedded linked list implementation instead of BSD's This removes cogl-queue.h and adds a copy of Wayland's embedded list implementation. The advantage of the Wayland model is that it is much simpler and so it is easier to follow. It also doesn't require defining a typedef for every list type. The downside is that there is only one list type which is a doubly-linked list where the head has a pointer to both the beginning and the end. The BSD implementation has many more combinations some of which we were taking advantage of to reduce the size of critical structs where we didn't need a pointer to the end of the list. The corresponding changes to uses of cogl-queue.h are: • COGL_STAILQ_* was used for onscreen the list of events and dirty notifications. This makes the size of the CoglContext grow by one pointer. • COGL_TAILQ_* was used for fences. • COGL_LIST_* for CoglClosures. In this case the list head now has an extra pointer which means CoglOnscreen will grow by the size of three pointers, but this doesn't seem like a particularly important struct to optimise for size anyway. • COGL_LIST_* was used for the list of foreign GLES2 offscreens. • COGL_TAILQ_* was used for the list of sub stacks in a CoglMemoryStack. • COGL_LIST_* was used to track the list of layers that haven't had code generated yet while generating a fragment shader for a pipeline. • COGL_LIST_* was used to track the pipeline hierarchy in CoglNode. The last part is a bit more controversial because it increases the size of CoglPipeline and CoglPipelineLayer by one pointer in order to have the redundant tail pointer for the list head. Normally we try to be very careful about the size of the CoglPipeline struct. Because CoglPipeline is slice-allocated, this effectively ends up adding two pointers to the size because GSlice rounds up to the size of two pointers. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 13abf613b15f571ba1fcf6d2eb831ffc6fa31324) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/driver/gl/cogl-pipeline-fragend-glsl.c doc/reference/cogl-2.0-experimental/Makefile.am
2013-06-08 18:03:25 -04:00
_cogl_list_init (&renderer->idle_closures);
Add api for queuing idle callback internally This adds a _cogl_poll_renderer_add_idle api that can be used internally for queuing an idle callback without needing to make any assumption about the system mainloop that is being used. This is now used to avoid having the _cogl_poll_renderer_dispatch() directly check for all kinds of events to dispatch, and to avoid having the winsys dispatch vfuncs need to directly know about CoglContext. This means we can now avoid having a back reference from CoglRenderer to the CoglContext. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit a1e169f18f4257caec58760adccfe4ec09b9805d)
2013-04-18 09:19:43 -04: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 13:50:49 -05:00
#ifdef COGL_HAS_XLIB_SUPPORT
renderer->xlib_enable_event_retrieval = TRUE;
#endif
win32: Automatically process windows messages when using a GMainLoop Previously the WGL winsys was expecting the application to send all windows messages to Cogl via the cogl_win32_renderer_handle_event function. When using a GLib main loop we can make this work transparently to the application with a GSource for the magic G_WIN32_MSG_HANDLE file descriptor. That causes the GMainLoop to wake up whenever a message is available. This patch makes the WGL winsys add that magic value as a source fd. This will only have any meaning if the application is using glib, but it shouldn't matter because the cogl_poll_renderer_get_info function is documented to only work on Unix-based winsys's anyway. This patch is an API break because by default Cogl will now start stealing all of the Windows messages. Something like Clutter that wants to handle its own event retrieval would now need to call cogl_win32_renderer_set_event_retrieval_enabled to stop Cogl from stealing the events. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 99a7f84d7149f24f3e86c5d3562f9f2632ff6df8)
2013-05-14 10:43:04 -04:00
#ifdef COGL_HAS_WIN32_SUPPORT
renderer->win32_enable_event_retrieval = TRUE;
#endif
wayland: Add API to prevent Cogl from dispatching the wayland display This adds cogl_wayland_renderer_set_event_dispatch_enabled() which can be used to prevent Cogl from adding the socket for the Wayland display to its list of file descriptors to poll. This can be used in applications that want to integrate Cogl with existing code that is reading from the Wayland socket itself. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit f5b8d98676ab3e90ad80459019c737ec2ff90aa4)
2013-07-04 08:14:04 -04:00
#ifdef COGL_HAS_EGL_PLATFORM_WAYLAND_SUPPORT
renderer->wayland_enable_event_dispatch = TRUE;
#endif
cogl-winsys-egl-kms: Add cogl_kms_renderer_set_kms_fd Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 7bc7ea4cb5e8134a3aeed9615477f4152b558509) Conflicts: cogl/winsys/cogl-winsys-egl-kms.c
2014-02-28 09:40:31 -05:00
#ifdef COGL_HAS_EGL_PLATFORM_KMS_SUPPORT
renderer->kms_fd = -1;
#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 12:06:50 -05:00
return _cogl_renderer_object_new (renderer);
}
Don't use #if with defines that are either defined or not COGL_HAS_* and COGL_ENABLE_DEBUG are either defined in config.h or not. So let's test against this, not against their truth value, this allow us to use -Wundef to catch undefined macros in preprocessor directives. (cherry picked from commit 73b62832f24711073b0876a6c0f5c61727842c1c)
2012-12-28 21:00:00 -05:00
#ifdef COGL_HAS_XLIB_SUPPORT
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 12:06:50 -05:00
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 09:16:24 -04: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 12:06:50 -05: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 17:34:30 -04: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 12:06:50 -05: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 17:34:30 -04: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 12:06:50 -05: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 13:50:49 -05: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 12:06:50 -05: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 09:16:24 -04: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 12:06:50 -05: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 17:34:30 -04: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 12:06:50 -05: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 13:50:49 -05:00
void
cogl_xlib_renderer_set_event_retrieval_enabled (CoglRenderer *renderer,
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool enable)
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 13:50:49 -05:00
{
_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 12:06:50 -05:00
#endif /* COGL_HAS_XLIB_SUPPORT */
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool
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 12:06:50 -05:00
cogl_renderer_check_onscreen_template (CoglRenderer *renderer,
CoglOnscreenTemplate *onscreen_template,
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
CoglError **error)
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 12:06:50 -05:00
{
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 08:28:33 -04: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 14:11:52 -05: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 08:28:33 -04: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 10:00:38 -04: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 12:06:50 -05:00
return TRUE;
}
cogl/cogl-renderer.c: Avoid Clash with Newer Windows SDKs The DriverCallback is a function that is defined by the Windows SDK 8.0+ headers, which was initially used for device driver development. The use of DriverCallback would cause a clash, causing things to break when built with newer Windows SDKs, so rename DriverCallback to CoglDriverCallback to avoid this problem. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2014-03-06 07:13:07 -05:00
typedef CoglBool (*CoglDriverCallback) (CoglDriverDescription *description,
void *user_data);
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 15:44:56 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
static void
foreach_driver_description (CoglDriver driver_override,
cogl/cogl-renderer.c: Avoid Clash with Newer Windows SDKs The DriverCallback is a function that is defined by the Windows SDK 8.0+ headers, which was initially used for device driver development. The use of DriverCallback would cause a clash, causing things to break when built with newer Windows SDKs, so rename DriverCallback to CoglDriverCallback to avoid this problem. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2014-03-06 07:13:07 -05:00
CoglDriverCallback callback,
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
void *user_data)
{
#ifdef COGL_DEFAULT_DRIVER
const CoglDriverDescription *default_driver = NULL;
#endif
int i;
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 13:15:54 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (driver_override != COGL_DRIVER_ANY)
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
for (i = 0; i < G_N_ELEMENTS (_cogl_drivers); i++)
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (_cogl_drivers[i].id == driver_override)
{
callback (&_cogl_drivers[i], user_data);
return;
}
}
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
g_warn_if_reached ();
return;
}
#ifdef COGL_DEFAULT_DRIVER
for (i = 0; i < G_N_ELEMENTS (_cogl_drivers); i++)
{
const CoglDriverDescription *desc = &_cogl_drivers[i];
if (g_ascii_strcasecmp (desc->name, COGL_DEFAULT_DRIVER) == 0)
{
default_driver = desc;
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
break;
}
}
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (default_driver)
{
if (!callback (default_driver, user_data))
return;
}
#endif
for (i = 0; i < G_N_ELEMENTS (_cogl_drivers); i++)
{
Make the default driver selectable at configure time When building COGL with multiple backends it can be useful to force a default driver to be selected. For example while for Debian we do want to build the GL renderer on ARM, GLESv2 is much more suitable as the default renderer on that platform. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 8a43aa7167b56784f7b50c557391b990861d594f)
2012-06-20 03:47:41 -04:00
#ifdef COGL_DEFAULT_DRIVER
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (&_cogl_drivers[i] == default_driver)
continue;
Make the default driver selectable at configure time When building COGL with multiple backends it can be useful to force a default driver to be selected. For example while for Debian we do want to build the GL renderer on ARM, GLESv2 is much more suitable as the default renderer on that platform. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 8a43aa7167b56784f7b50c557391b990861d594f)
2012-06-20 03:47:41 -04:00
#endif
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (!callback (&_cogl_drivers[i], user_data))
return;
}
}
static CoglDriver
driver_name_to_id (const char *name)
{
int i;
for (i = 0; i < G_N_ELEMENTS (_cogl_drivers); i++)
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 15:44:56 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (g_ascii_strcasecmp (_cogl_drivers[i].name, name) == 0)
return _cogl_drivers[i].id;
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 15:44:56 -04:00
}
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
return COGL_DRIVER_ANY;
}
static const char *
driver_id_to_name (CoglDriver id)
{
switch (id)
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
case COGL_DRIVER_GL:
return "gl";
case COGL_DRIVER_GL3:
return "gl3";
case COGL_DRIVER_GLES1:
return "gles1";
case COGL_DRIVER_GLES2:
return "gles2";
Adds "webgl" driver This adds a COGL_DRIVER_WEBGL enum and a new driver description for webgl in cogl-renderer.c. This also adds a COGL_DRIVER_FLAG_OPENGL_WEB driver flag and a HAVE_COGL_WEBGL define which we can start to use to handle special cases where webgl differs from gles2. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 2c167b7a4ee56241827322bbe7cb287b0628437c)
2013-05-11 15:02:43 -04:00
case COGL_DRIVER_WEBGL:
return "webgl";
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
case COGL_DRIVER_NOP:
return "nop";
case COGL_DRIVER_ANY:
g_warn_if_reached ();
return "any";
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
}
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 15:44:56 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
g_warn_if_reached ();
return "unknown";
}
typedef struct _SatisfyConstraintsState
{
GList *constraints;
const CoglDriverDescription *driver_description;
} SatisfyConstraintsState;
static CoglBool
satisfy_constraints (CoglDriverDescription *description,
void *user_data)
{
SatisfyConstraintsState *state = user_data;
GList *l;
for (l = state->constraints; l; l = l->next)
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 15:44:56 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
CoglRendererConstraint constraint = GPOINTER_TO_UINT (l->data);
renderer: Only check certain constraints when selecting a driver Only COGL_RENDERER_CONSTRAINT_SUPPORTS_COGL_GLES2 affects the driver selection and all of the the other constraints are only relevant to the winsys selection. However Cogl was trying to apply all of the constraints to the driver selection which meant that if any other constraint was specified then it would always fail. This patch makes the driver selection filter out all other constraints based on a mask defined in cogl-renderer-private.h. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit f07febc8913b97fb828e7f2cc2857813af2d3657)
2013-06-27 04:30:04 -04:00
/* Most of the constraints only affect the winsys selection so
* we'll filter them out */
if (!(constraint & COGL_RENDERER_DRIVER_CONSTRAINTS))
continue;
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
/* If the driver doesn't satisfy any constraint then continue
* to the next driver description */
if (!(constraint & description->constraints))
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 15:44:56 -04:00
}
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
state->driver_description = description;
return FALSE;
}
static CoglBool
_cogl_renderer_choose_driver (CoglRenderer *renderer,
CoglError **error)
{
const char *driver_name = g_getenv ("COGL_DRIVER");
CoglDriver driver_override = COGL_DRIVER_ANY;
const char *invalid_override = NULL;
const char *libgl_name;
SatisfyConstraintsState state;
const CoglDriverDescription *desc;
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
int i;
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (!driver_name)
driver_name = _cogl_config_driver;
if (driver_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 15:44:56 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
driver_override = driver_name_to_id (driver_name);
if (driver_override == COGL_DRIVER_ANY)
invalid_override = driver_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 15:44:56 -04:00
}
renderer: Don't allow the COGL_DRIVER env var to override application Since e07d0fc7441 the COGL_DRIVER environment variable was able to override the application's driver selection. This doesn't seem like a good idea because if the application is specifying a driver explicitly then presumably it can not work with any other driver. This patch changes it so that if a driver is selected in the configuration and by the application then they must match, otherwise it will fail with a CoglError. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 4e0942d74c8d69aa48e0176bfecf27f64a950d0f)
2013-06-27 04:57:02 -04:00
if (renderer->driver_override != COGL_DRIVER_ANY)
{
if (driver_override != COGL_DRIVER_ANY &&
renderer->driver_override != driver_override)
{
_cogl_set_error (error,
COGL_RENDERER_ERROR,
COGL_RENDERER_ERROR_BAD_CONSTRAINT,
"Application driver selection conflicts with driver "
"specified in configuration");
return FALSE;
}
driver_override = renderer->driver_override;
}
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 15:44:56 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (driver_override != COGL_DRIVER_ANY)
Adds a NOP driver This adds a new "nop" driver that does nothing. This can be selected at runtime either with the COGL_DRIVER=nop environment variable or by passing COGL_DRIVER_NOP to cogl_renderer_set_driver() Adding the nop driver gives us a way to test workloads without any driver and hardware overheads which can help us understand how Cogl's state tracking performs in isolation. Having a nop driver can also serve as an shell/outline for creating other drivers later. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 90587418233b6438290741d80aedf193ae660cad)
2012-09-12 17:39:46 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
CoglBool found = FALSE;
int i;
for (i = 0; i < G_N_ELEMENTS (_cogl_drivers); i++)
{
if (_cogl_drivers[i].id == driver_override)
{
found = TRUE;
break;
}
}
if (!found)
invalid_override = driver_id_to_name (driver_override);
Adds a NOP driver This adds a new "nop" driver that does nothing. This can be selected at runtime either with the COGL_DRIVER=nop environment variable or by passing COGL_DRIVER_NOP to cogl_renderer_set_driver() Adding the nop driver gives us a way to test workloads without any driver and hardware overheads which can help us understand how Cogl's state tracking performs in isolation. Having a nop driver can also serve as an shell/outline for creating other drivers later. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 90587418233b6438290741d80aedf193ae660cad)
2012-09-12 17:39:46 -04:00
}
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (invalid_override)
{
_cogl_set_error (error,
COGL_RENDERER_ERROR,
COGL_RENDERER_ERROR_BAD_CONSTRAINT,
"Driver \"%s\" is not available",
invalid_override);
return FALSE;
}
state.driver_description = NULL;
state.constraints = renderer->constraints;
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 15:44:56 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
foreach_driver_description (driver_override,
satisfy_constraints,
&state);
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (!state.driver_description)
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error,
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
COGL_RENDERER_ERROR,
COGL_RENDERER_ERROR_BAD_CONSTRAINT,
"No suitable driver found");
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
return FALSE;
}
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 15:44:56 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
desc = state.driver_description;
renderer->driver = desc->id;
renderer->driver_vtable = desc->vtable;
renderer->texture_driver = desc->texture_driver;
libgl_name = desc->libgl_name;
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
memset(renderer->private_features, 0, sizeof (renderer->private_features));
for (i = 0; desc->private_features[i] != -1; i++)
COGL_FLAGS_SET (renderer->private_features,
desc->private_features[i], 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 15:44:56 -04:00
#ifndef HAVE_DIRECTLY_LINKED_GL_LIBRARY
Use COGL_FLAGS_* for the context's private feature flags Previously the private feature flags were stored in an enum and we already had 31 flags. Adding the 32nd flag would presumably make it add -2³¹ as one of the values which might cause problems. To avoid this we'll just use an fixed-size array of longs and use indices for the enum values like we do for the public features. A slight complication with this is in the CoglDriverDescription where we were previously using a static intialised value to describe the set of features that the driver supports. We can't easily do this with the flags array so instead the features are stored in a fixed-size array of indices. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3) Conflicts: cogl/cogl-context-private.h cogl/cogl-context.c cogl/cogl-private.h cogl/cogl-renderer.c cogl/driver/gl/cogl-pipeline-opengl.c cogl/driver/gl/gl/cogl-driver-gl.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c cogl/driver/gl/gles/cogl-driver-gles.c cogl/driver/nop/cogl-driver-nop.c
2013-11-25 11:11:36 -05:00
if (COGL_FLAGS_GET (renderer->private_features,
COGL_PRIVATE_FEATURE_ANY_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 15:44:56 -04:00
{
Adds a NOP driver This adds a new "nop" driver that does nothing. This can be selected at runtime either with the COGL_DRIVER=nop environment variable or by passing COGL_DRIVER_NOP to cogl_renderer_set_driver() Adding the nop driver gives us a way to test workloads without any driver and hardware overheads which can help us understand how Cogl's state tracking performs in isolation. Having a nop driver can also serve as an shell/outline for creating other drivers later. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 90587418233b6438290741d80aedf193ae660cad)
2012-09-12 17:39:46 -04:00
renderer->libgl_module = g_module_open (libgl_name,
G_MODULE_BIND_LAZY);
if (renderer->libgl_module == NULL)
{
_cogl_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;
}
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 15:44:56 -04:00
}
#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 12:06:50 -05:00
/* Final connection API */
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
cogl_renderer_connect (CoglRenderer *renderer, CoglError **error)
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 12:06:50 -05: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 06:29:08 -05:00
int i;
GString *error_message;
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
CoglBool constraints_failed = 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 06:29:08 -05: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 12:06:50 -05: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 15:44:56 -04: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 06:29:08 -05: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]();
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
CoglError *tmp_error = NULL;
renderer: Adds api to add/remove selection constraints This allows applications to specify certain constraints that feed into the process of selecting a CoglRenderer backend. For example applications might depend on x11 for handling input and so they require a backend that's also based on x11.
2012-01-13 11:48:26 -05:00
GList *l;
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
CoglBool skip_due_to_constraints = FALSE;
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 11:24:51 -04: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 08:29:12 -04: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 13:15:54 -04: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 12:13:17 -05: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 08:29:12 -04: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 11:24:51 -04:00
renderer: Adds api to add/remove selection constraints This allows applications to specify certain constraints that feed into the process of selecting a CoglRenderer backend. For example applications might depend on x11 for handling input and so they require a backend that's also based on x11.
2012-01-13 11:48:26 -05:00
for (l = renderer->constraints; l; l = l->next)
{
CoglRendererConstraint constraint = GPOINTER_TO_UINT (l->data);
if (!(winsys->constraints & constraint))
{
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
skip_due_to_constraints = TRUE;
renderer: Adds api to add/remove selection constraints This allows applications to specify certain constraints that feed into the process of selecting a CoglRenderer backend. For example applications might depend on x11 for handling input and so they require a backend that's also based on x11.
2012-01-13 11:48:26 -05:00
break;
}
}
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
if (skip_due_to_constraints)
{
constraints_failed |= TRUE;
continue;
}
renderer: Adds api to add/remove selection constraints This allows applications to specify certain constraints that feed into the process of selecting a CoglRenderer backend. For example applications might depend on x11 for handling input and so they require a backend that's also based on x11.
2012-01-13 11:48:26 -05: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-24 20:49:44 -04: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 06:29:08 -05:00
if (!winsys->renderer_connect (renderer, &tmp_error))
{
g_string_append_c (error_message, '\n');
g_string_append (error_message, tmp_error->message);
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
cogl_error_free (tmp_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 06:29:08 -05:00
}
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 08:28:33 -04: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 06:29:08 -05:00
if (!renderer->connected)
{
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
if (constraints_failed)
{
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_RENDERER_ERROR,
Adds gles2-context renderer constraint This adds a new renderer constraint enum: COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT that can be used by applications to ensure the renderer they connect to has support for creating a GLES2 context via cogl_gles2_context_new(). The cogl-gles2-context and cogl-gles2-gears examples and the conformance tests have been updated to use this constraint. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
2012-04-26 07:18:56 -04:00
COGL_RENDERER_ERROR_BAD_CONSTRAINT,
"Failed to connected to any renderer due to constraints");
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 06:29:08 -05:00
renderer->winsys_vtable = NULL;
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
_cogl_set_error (error, COGL_WINSYS_ERROR,
Add 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 06:29:08 -05:00
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 12:06:50 -05: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 11:41:41 -04: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 08:38:50 -04: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 11:41:41 -04: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 08:38:50 -04: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 11:41:41 -04: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 08:38:50 -04: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 11:41:41 -04: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 08:29:12 -04: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 17:34:30 -04: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 08:29:12 -04: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 17:34:30 -04: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 08:29:12 -04: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 07:30:02 -04:00
void *
_cogl_renderer_get_proc_address (CoglRenderer *renderer,
Don't use eglGetProcAddress to retrieve core functions According to the EGL spec, eglGetProcAddress should only be used to retrieve extension functions. It also says that returning non-NULL does not mean the extension is available so you could interpret this as saying that the function is allowed to return garbage for core functions. This seems to happen at least for the Android implementation of EGL. To workaround this the winsys's are now passed down a flag to say whether the function is from the core API. This information is already in the gl-prototypes headers as the minimum core GL version and as a pair of flags to specify whether it is available in core GLES1 and GLES2. If the function is in core the EGL winsys will now avoid using eglGetProcAddress and always fallback to querying the library directly with the GModule API. The GLX winsys is left alone because glXGetProcAddress apparently supports querying core API and extension functions. The WGL winsys could ideally be changed because wglGetProcAddress should also only be used for extension functions but the situation is slightly different because WGL considers anything from GL > 1.1 to be an extension so it would need a bit more information to determine whether to query the function directly from the library. The SDL winsys is also left alone because it's not as easy to portably determine which GL library SDL has chosen to load in order to resolve the symbols directly. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 72089730ad06ccdd38a344279a893965ae68cec1) Since we aren't able to break API on the 1.12 branch cogl_get_proc_address is still supported but isn't easily able to determine whether the given name corresponds to a core symbol or not. For now we just assume the symbol being queried isn't part of the core GL api and update the documentation accordingly.
2012-06-20 07:42:31 -04:00
const char *name,
CoglBool in_core)
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 07:30:02 -04:00
{
const CoglWinsysVtable *winsys = _cogl_renderer_get_winsys (renderer);
Don't use eglGetProcAddress to retrieve core functions According to the EGL spec, eglGetProcAddress should only be used to retrieve extension functions. It also says that returning non-NULL does not mean the extension is available so you could interpret this as saying that the function is allowed to return garbage for core functions. This seems to happen at least for the Android implementation of EGL. To workaround this the winsys's are now passed down a flag to say whether the function is from the core API. This information is already in the gl-prototypes headers as the minimum core GL version and as a pair of flags to specify whether it is available in core GLES1 and GLES2. If the function is in core the EGL winsys will now avoid using eglGetProcAddress and always fallback to querying the library directly with the GModule API. The GLX winsys is left alone because glXGetProcAddress apparently supports querying core API and extension functions. The WGL winsys could ideally be changed because wglGetProcAddress should also only be used for extension functions but the situation is slightly different because WGL considers anything from GL > 1.1 to be an extension so it would need a bit more information to determine whether to query the function directly from the library. The SDL winsys is also left alone because it's not as easy to portably determine which GL library SDL has chosen to load in order to resolve the symbols directly. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 72089730ad06ccdd38a344279a893965ae68cec1) Since we aren't able to break API on the 1.12 branch cogl_get_proc_address is still supported but isn't easily able to determine whether the given name corresponds to a core symbol or not. For now we just assume the symbol being queried isn't part of the core GL api and update the documentation accordingly.
2012-06-20 07:42:31 -04:00
return winsys->renderer_get_proc_address (renderer, name, in_core);
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 07:30:02 -04:00
}
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 12:26:44 -04: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)
Support cogl_renderer_get_n_fragment_texture_units() for ARBfp There is a cogl_renderer_get_n_fragment_texture_units() function which is documented to return the number of texture units that are accessible from a fragment program. This just directly returns the value from GL_MAX_TEXTURE_IMAGE_UNITS which is available in either the GLSL extensions or the ARBfp extension. Clutter-GST relies on this to determine whether it can use a program to convert the YUV data on the GPU. When the GL3 driver was added in 66c9db993595b this was changed to only query the value when the GLSL feature is available. Previously it would always query the value when the GL or GLES2 driver is used. This change makes sense on master because there is no API for an application to make its own ARBfp programs so the only way to access texture units from a program is via GLSL. However on the 1.14 branch this patch broke clutter-gst when GLSL is disabled because it thinks the ARBfp programs can't use multi-texturing. This patch just changes it to also query the value when ARBfp support is available. Note: it's probably note a good idea to apply this patch to master, but only to the 1.14 branch. On master the function probably needs to be changed anyway because it is using _COGL_GET_CONTEXT(). Reviewed-by: Robert Bragg <robert@linux.intel.com>
2013-01-30 08:53:48 -05:00
if (cogl_has_feature (ctx, COGL_FEATURE_ID_GLSL) ||
cogl_has_feature (ctx, COGL_FEATURE_ID_ARBFP))
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 12:26:44 -04:00
GE (ctx, glGetIntegerv (GL_MAX_TEXTURE_IMAGE_UNITS, &n));
#endif
return n;
}
renderer: Adds api to add/remove selection constraints This allows applications to specify certain constraints that feed into the process of selecting a CoglRenderer backend. For example applications might depend on x11 for handling input and so they require a backend that's also based on x11.
2012-01-13 11:48:26 -05:00
void
renderer: fix s/contraint/constraint/ typo The recent patch to add an api for explicitly constraining how a renderer backend is chosen had a typo which this patch fixes. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-17 09:49:28 -05:00
cogl_renderer_add_constraint (CoglRenderer *renderer,
CoglRendererConstraint constraint)
renderer: Adds api to add/remove selection constraints This allows applications to specify certain constraints that feed into the process of selecting a CoglRenderer backend. For example applications might depend on x11 for handling input and so they require a backend that's also based on x11.
2012-01-13 11:48:26 -05:00
{
g_return_if_fail (!renderer->connected);
renderer->constraints = g_list_prepend (renderer->constraints,
GUINT_TO_POINTER (constraint));
}
void
cogl_renderer_remove_constraint (CoglRenderer *renderer,
CoglRendererConstraint constraint)
{
g_return_if_fail (!renderer->connected);
renderer->constraints = g_list_remove (renderer->constraints,
GUINT_TO_POINTER (constraint));
}
renderer: Adds getters/setters for driver preference This adds api for explicitly choosing what underlying driver cogl should use internally for rendering as well as api for querying back what driver is actually in use. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-23 11:41:27 -05:00
void
cogl_renderer_set_driver (CoglRenderer *renderer,
CoglDriver driver)
{
_COGL_RETURN_IF_FAIL (!renderer->connected);
renderer->driver_override = driver;
}
CoglDriver
cogl_renderer_get_driver (CoglRenderer *renderer)
{
_COGL_RETURN_VAL_IF_FAIL (renderer->connected, 0);
return renderer->driver;
}
renderer: expose CoglOutputs This adds a cogl_renderer_foreach_output() function that can be used to iterate the display outputs for a particular renderer. This also updates cogl-info to use this new api so it can dump out all the output information. Reviewed-by: Owen W. Taylor <otaylor@fishsoup.net> (cherry picked from commit a2abf4c4c1fd5aeafd761f965d07a0fe9a362afc)
2013-01-20 20:18:25 -05:00
void
cogl_renderer_foreach_output (CoglRenderer *renderer,
CoglOutputCallback callback,
void *user_data)
{
GList *l;
_COGL_RETURN_IF_FAIL (renderer->connected);
_COGL_RETURN_IF_FAIL (callback != NULL);
for (l = renderer->outputs; l; l = l->next)
callback (l->data, user_data);
}
Reference in New Issue Copy Permalink