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
9d2fc82077
mutter/cogl/cogl-display.c

176 lines
4.2 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
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2011 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
* Boston, MA 02111-1307, USA.
*
* Authors:
* Robert Bragg <robert@linux.intel.com>
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
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
#include <string.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"
#include "cogl-display-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
#include "cogl-renderer-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-winsys-private.h"
display: inc cogl-wayland-server.h if needed Since 0773107deb9ede the prototype for cogl_wayland_display_set_compositor_display() has moved into cogl-wayland-server.h but cogl-display.c wasn't updated to include this header. (cherry picked from commit f6ccff9992fcfb9497ce91dd299460362476ba7a)
2012-08-06 12:53:46 -04:00
#ifdef COGL_HAS_WAYLAND_EGL_SERVER_SUPPORT
#include "cogl-wayland-server.h"
#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
static void _cogl_display_free (CoglDisplay *display);
COGL_OBJECT_DEFINE (Display, display);
egl: Make sure to free the underlying egl objects when the display is freed If the display has been setup up, we should destroy the underlying objects that the winsys has created. This can be done by calling the winsys->destroy_display() function in _free. Then, in that function, and for the NULL and GDL EGL platform we can destroy the surface we have created in the setup_display() function (through create_context()). This allows to have clutter create a "dummy" display in cogl_renderer_check_onscreen_template(), then free it, then recreate the context and the surface that will be the final ones. https://bugzilla.gnome.org/show_bug.cgi?id=655355
2011-07-26 10:39:44 -04:00
static const CoglWinsysVtable *
_cogl_display_get_winsys (CoglDisplay *display)
{
return display->renderer->winsys_vtable;
}
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_display_free (CoglDisplay *display)
{
egl: Make sure to free the underlying egl objects when the display is freed If the display has been setup up, we should destroy the underlying objects that the winsys has created. This can be done by calling the winsys->destroy_display() function in _free. Then, in that function, and for the NULL and GDL EGL platform we can destroy the surface we have created in the setup_display() function (through create_context()). This allows to have clutter create a "dummy" display in cogl_renderer_check_onscreen_template(), then free it, then recreate the context and the surface that will be the final ones. https://bugzilla.gnome.org/show_bug.cgi?id=655355
2011-07-26 10:39:44 -04:00
const CoglWinsysVtable *winsys;
if (display->setup)
{
winsys = _cogl_display_get_winsys (display);
winsys->display_destroy (display);
display->setup = 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
if (display->renderer)
{
cogl_object_unref (display->renderer);
display->renderer = NULL;
}
if (display->onscreen_template)
{
cogl_object_unref (display->onscreen_template);
display->onscreen_template = NULL;
}
g_slice_free (CoglDisplay, display);
}
CoglDisplay *
cogl_display_new (CoglRenderer *renderer,
CoglOnscreenTemplate *onscreen_template)
{
CoglDisplay *display = g_slice_new0 (CoglDisplay);
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 = 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
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
display->renderer = renderer;
if (renderer)
cogl_object_ref (renderer);
else
display->renderer = cogl_renderer_new ();
if (!cogl_renderer_connect (display->renderer, &error))
fix cogl_context_new crash if fail to connect renderer If a NULL display is passed to cogl_context_new() then it has to implicitly create a CoglRenderer and CoglDisplay and propagate any resulting errors back to the user. Previously the implementation relied on passing a NULL renderer to cogl_display_new() as the means for implicitly connecting to a renderer. The problem with this though is that cogl_display_new() isn't designed to ever return NULL but if it failed to connect to a renderer automatically it would do and then cogl_context_new would pass NULL to cogl_display_setup() leading to a crash. This patch changes the implementation of cogl_context_new() to now explicitly create a CoglRenderer and connect to it if a NULL display is given. This way we can easily propagate any errors. In addition cogl_display_new has been changed to abort if it fails to implicitly connect to a renderer due to a NULL renderer argument. An application needing to gracefully handle problems connecting to a renderer at runtime should manually instantiate and connect a renderer passing a GError argument to cogl_renderer_connect. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-04-10 14:21:55 -04:00
g_error ("Failed to connect to renderer: %s\n", error->message);
Adds renderer,display,onscreen-template and swap-chain stubs As part of the process of splitting Cogl out as a standalone graphics API we need to introduce some API concepts that will allow us to initialize a new CoglContext when Clutter isn't there to handle that for us... The new objects roughly in the order that they are (optionally) involved in constructing a context are: CoglRenderer, CoglOnscreenTemplate, CoglSwapChain and CoglDisplay. Conceptually a CoglRenderer represents a means for rendering. Cogl supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are accessed through a number of different windowing APIs such as GLX, EGL, SDL or WGL and more. Potentially in the future Cogl could render using D3D or even by using libdrm and directly banging the hardware. All these choices are wrapped up in the configuration of a CoglRenderer. Conceptually a CoglDisplay represents a display pipeline for a renderer. Although Cogl doesn't aim to provide a detailed abstraction of display hardware, on some platforms we can give control over multiple display planes (On TV platforms for instance video content may be on one plane and 3D would be on another so a CoglDisplay lets you select the plane up-front.) Another aspect of CoglDisplay is that it lets us negotiate a display pipeline that best supports the type of CoglOnscreen framebuffers we are planning to create. For instance if you want transparent CoglOnscreen framebuffers then we have to be sure the display pipeline wont discard the alpha component of your framebuffers. Or if you want to use double/tripple buffering that requires support from the display pipeline. CoglOnscreenTemplate and CoglSwapChain are how we describe our default CoglOnscreen framebuffer configuration which can affect the configuration of the display pipeline. The default/simple way we expect most CoglContexts to be constructed will be via something like: if (!cogl_context_new (NULL, &error)) g_error ("Failed to construct a CoglContext: %s", error->message); Where that NULL is for an optional "display" parameter and NULL says to Cogl "please just try to do something sensible". If you want some more control though you can manually construct a CoglDisplay something like: display = cogl_display_new (NULL, NULL); cogl_gdl_display_set_plane (display, plane); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message); And in a similar fashion to cogl_context_new() you can optionally pass a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to just do something sensible. If you need to change the CoglOnscreen defaults you can provide a template something like: chain = cogl_swap_chain_new (); cogl_swap_chain_set_has_alpha (chain, TRUE); cogl_swap_chain_set_length (chain, 3); onscreen_template = cogl_onscreen_template_new (chain); cogl_onscreen_template_set_pixel_format (onscreen_template, COGL_PIXEL_FORMAT_RGB565); display = cogl_display_new (NULL, onscreen_template); if (!cogl_display_setup (display, &error)) g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-02-25 12:06:50 -05:00
display->setup = FALSE;
egl-gdl: Provide defaults to be able to initialize a "dummy" context If we are being called without any GDL specific call (either the plane we want to render to or the swap chain length) we can provide sane defaults to still be able to create a context and a surface. https://bugzilla.gnome.org/show_bug.cgi?id=655355
2011-07-26 10:32:47 -04:00
#ifdef COGL_HAS_EGL_PLATFORM_GDL_SUPPORT
display->gdl_plane = GDL_PLANE_ID_UPP_C;
#endif
display: add _set_onscreen_template() api Currently it's only possible to set an onscreen template on a CoglDisplay by passing a template to cogl_display_new(). For applications that want to deal with fallbacks then they may want to replace the onscreen template so this adds a cogl_display_set_onscreen_template() function. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f307c9545791dae5472a9568fef6b31b3bf52854)
2013-03-01 09:50:43 -05:00
display = _cogl_display_object_new (display);
cogl_display_set_onscreen_template (display, onscreen_template);
return display;
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: Add an accessor to get the renderer out of a display https://bugzilla.gnome.org/show_bug.cgi?id=657347 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-08-25 12:35:34 -04:00
CoglRenderer *
cogl_display_get_renderer (CoglDisplay *display)
{
return display->renderer;
}
display: add _set_onscreen_template() api Currently it's only possible to set an onscreen template on a CoglDisplay by passing a template to cogl_display_new(). For applications that want to deal with fallbacks then they may want to replace the onscreen template so this adds a cogl_display_set_onscreen_template() function. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f307c9545791dae5472a9568fef6b31b3bf52854)
2013-03-01 09:50:43 -05:00
void
cogl_display_set_onscreen_template (CoglDisplay *display,
CoglOnscreenTemplate *onscreen_template)
{
_COGL_RETURN_IF_FAIL (display->setup == FALSE);
if (onscreen_template)
cogl_object_ref (onscreen_template);
if (display->onscreen_template)
cogl_object_unref (display->onscreen_template);
display->onscreen_template = onscreen_template;
/* NB: we want to maintain the invariable that there is always an
* onscreen template associated with a CoglDisplay... */
if (!onscreen_template)
display->onscreen_template = cogl_onscreen_template_new (NULL);
}
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_display_setup (CoglDisplay *display,
Adds CoglError api Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46) Note: Since we can't change the Cogl 1.x api the patch was changed to not rename _error_quark() functions to be _error_domain() functions and although it's a bit ugly, instead of providing our own CoglError type that's compatible with GError we simply #define CoglError to GError unless Cogl is built with glib disabled. Note: this patch does technically introduce an API break since it drops the cogl_error_get_type() symbol generated by glib-mkenum (Since the CoglError enum was replaced by a CoglSystemError enum) but for now we are assuming that this will not affect anyone currently using the Cogl API. If this does turn out to be a problem in practice then we would be able to fix this my manually copying an implementation of cogl_error_get_type() generated by glib-mkenum into a compatibility source file and we could also define the original COGL_ERROR_ enums for compatibility too. Note: another minor concern with cherry-picking this patch to the 1.14 branch is that an api scanner would be lead to believe that some APIs have changed, and for example the gobject-introspection parser which understands the semantics of GError will not understand the semantics of CoglError. We expect most people that have tried to use gobject-introspection with Cogl already understand though that it is not well suited to generating bindings of the Cogl api anyway and we aren't aware or anyone depending on such bindings for apis involving GErrors. (GnomeShell only makes very-very minimal use of Cogl via the gjs bindings for the cogl_rectangle and cogl_color apis.) The main reason we have cherry-picked this patch to the 1.14 branch even given the above concerns is that without it it would become very awkward for us to cherry-pick other beneficial patches from master.
2012-08-31 14:28:27 -04:00
CoglError **error)
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
const CoglWinsysVtable *winsys;
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 (display->setup)
return TRUE;
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
winsys = _cogl_display_get_winsys (display);
if (!winsys->display_setup (display, 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;
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->setup = TRUE;
return TRUE;
}
EGL: Updates GDL platform support The GDL API is used for example on intel ce4100 (aka Sodaville) based systems as a way to allocate memory that can be composited using the platforms overlay hardware. This updates the Cogl EGL winsys and the support in Clutter so we can continue to support these platforms.
2011-03-04 07:50:39 -05:00
#ifdef COGL_HAS_EGL_PLATFORM_GDL_SUPPORT
void
cogl_gdl_display_set_plane (CoglDisplay *display,
egl-gdl: struct gdl_plane never was a valid type The enum for the planes is called gdl_plant_id_t. https://bugzilla.gnome.org/show_bug.cgi?id=655355
2011-07-22 12:06:11 -04:00
gdl_plane_id_t plane)
EGL: Updates GDL platform support The GDL API is used for example on intel ce4100 (aka Sodaville) based systems as a way to allocate memory that can be composited using the platforms overlay hardware. This updates the Cogl EGL winsys and the support in Clutter so we can continue to support these platforms.
2011-03-04 07:50:39 -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_IF_FAIL (display->setup == FALSE);
EGL: Updates GDL platform support The GDL API is used for example on intel ce4100 (aka Sodaville) based systems as a way to allocate memory that can be composited using the platforms overlay hardware. This updates the Cogl EGL winsys and the support in Clutter so we can continue to support these platforms.
2011-03-04 07:50:39 -05:00
display->gdl_plane = plane;
}
#endif
Adds _cogl_wayland_texture_2d_new_from_buffer API This adds internal API to be able to wrap a wayland buffer as a CoglTexture2D. There is a --enable-wayland-egl-server option to decide if Cogl should support this feature and potentially any EGL based winsys could support this through the EGL_KHR_image_base and EGL_WL_bind_display extensions.
2011-05-24 20:37:56 -04:00
#ifdef COGL_HAS_WAYLAND_EGL_SERVER_SUPPORT
void
cogl_wayland_display_set_compositor_display (CoglDisplay *display,
struct wl_display *wayland_display)
{
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 (display->setup == FALSE);
Adds _cogl_wayland_texture_2d_new_from_buffer API This adds internal API to be able to wrap a wayland buffer as a CoglTexture2D. There is a --enable-wayland-egl-server option to decide if Cogl should support this feature and potentially any EGL based winsys could support this through the EGL_KHR_image_base and EGL_WL_bind_display extensions.
2011-05-24 20:37:56 -04:00
display->wayland_compositor_display = wayland_display;
}
#endif
Reference in New Issue Copy Permalink