mutter/cogl/cogl-context.c

410 lines
13 KiB
C
Raw Normal View History

/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2007,2008,2009 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
*
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "cogl.h"
#include "cogl-internal.h"
#include "cogl-profile.h"
#include "cogl-util.h"
#include "cogl-context.h"
#include "cogl-journal-private.h"
#include "cogl-texture-private.h"
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
#include "cogl-pipeline-private.h"
#include "cogl-pipeline-opengl-private.h"
#include "cogl-framebuffer-private.h"
#include "cogl2-path.h"
#include <string.h>
#ifdef HAVE_COGL_GL
#include "cogl-pipeline-arbfp-private.h"
#define glActiveTexture _context->drv.pf_glActiveTexture
#endif
/* This isn't defined in the GLES headers */
#ifndef GL_POINT_SPRITE
#define GL_POINT_SPRITE 0x8861
#endif
extern void
_cogl_create_context_driver (CoglContext *context);
extern void
_cogl_create_context_winsys (CoglContext *context);
extern void
_cogl_destroy_context_winsys (CoglContext *context);
static CoglContext *_context = NULL;
static gboolean gl_is_indirect = FALSE;
static void
_cogl_init_feature_overrides (CoglContext *ctx)
{
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_VBOS))
ctx->feature_flags &= ~COGL_FEATURE_VBOS;
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_PBOS))
ctx->feature_flags &= ~COGL_FEATURE_PBOS;
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_ARBFP))
ctx->feature_flags &= ~COGL_FEATURE_SHADERS_ARBFP;
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_GLSL))
ctx->feature_flags &= ~COGL_FEATURE_SHADERS_GLSL;
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_NPOT_TEXTURES))
ctx->feature_flags &= ~(COGL_FEATURE_TEXTURE_NPOT |
COGL_FEATURE_TEXTURE_NPOT_BASIC |
COGL_FEATURE_TEXTURE_NPOT_MIPMAP |
COGL_FEATURE_TEXTURE_NPOT_REPEAT);
}
static gboolean
cogl_create_context (void)
{
GLubyte default_texture_data[] = { 0xff, 0xff, 0xff, 0x0 };
cogl: improves header and coding style consistency We've had complaints that our Cogl code/headers are a bit "special" so this is a first pass at tidying things up by giving them some consistency. These changes are all consistent with how new code in Cogl is being written, but the style isn't consistently applied across all code yet. There are two parts to this patch; but since each one required a large amount of effort to maintain tidy indenting it made sense to combine the changes to reduce the time spent re indenting the same lines. The first change is to use a consistent style for declaring function prototypes in headers. Cogl headers now consistently use this style for prototypes: return_type cogl_function_name (CoglType arg0, CoglType arg1); Not everyone likes this style, but it seems that most of the currently active Cogl developers agree on it. The second change is to constrain the use of redundant glib data types in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all been replaced with int, unsigned int, float, long, unsigned long and char respectively. When talking about pixel data; use of guchar has been replaced with guint8, otherwise unsigned char can be used. The glib types that we continue to use for portability are gboolean, gint{8,16,32,64}, guint{8,16,32,64} and gsize. The general intention is that Cogl should look palatable to the widest range of C programmers including those outside the Gnome community so - especially for the public API - we want to minimize the number of foreign looking typedefs.
2010-02-10 01:57:32 +00:00
unsigned long enable_flags = 0;
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 13:34:34 +00:00
CoglHandle window_buffer;
int i;
if (_context != NULL)
return FALSE;
#ifdef CLUTTER_ENABLE_PROFILE
/* We need to be absolutely sure that uprof has been initialized
* before calling _cogl_uprof_init. uprof_init (NULL, NULL)
* will be a NOP if it has been initialized but it will also
* mean subsequent parsing of the UProf GOptionGroup will have no
* affect.
*
* Sadly GOptionGroup based library initialization is extremely
* fragile by design because GOptionGroups have no notion of
* dependencies and so the order things are initialized isn't
* currently under tight control.
*/
uprof_init (NULL, NULL);
_cogl_uprof_init ();
#endif
/* Allocate context memory */
_context = (CoglContext*) g_malloc (sizeof (CoglContext));
/* Init default values */
_context->feature_flags = 0;
_context->feature_flags_private = 0;
_context->texture_types = NULL;
_context->buffer_types = NULL;
/* Initialise the driver specific state */
/* TODO: combine these two into one function */
_cogl_create_context_driver (_context);
_cogl_features_init ();
_cogl_init_feature_overrides (_context);
_cogl_create_context_winsys (_context);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_cogl_pipeline_init_default_pipeline ();
_cogl_pipeline_init_default_layers ();
_cogl_pipeline_init_state_hash_functions ();
_cogl_pipeline_init_layer_state_hash_functions ();
_context->enable_flags = 0;
_context->enable_backface_culling = FALSE;
_context->flushed_front_winding = COGL_FRONT_WINDING_COUNTER_CLOCKWISE;
_context->indirect = gl_is_indirect;
[cogl] Make sure we draw upside down to offscreen draw buffers First a few notes about Cogl coordinate systems: - Cogl defines the window origin, viewport origin and texture coordinates origin to be top left unlike OpenGL which defines them as bottom left. - Cogl defines the modelview and projection identity matrices in exactly the same way as OpenGL. - I.e. we believe that for 2D centric constructs: windows/framebuffers, viewports and textures developers are more used to dealing with a top left origin, but when modeling objects in 3D; an origin at the center with y going up is quite natural. The way Cogl handles textures is by uploading data upside down in OpenGL terms so that bottom left becomes top left. (Note: This also has the benefit that we don't need to flip the data we get from image decoding libraries since they typically also consider top left to be the image origin.) The viewport and window coords are mostly handled with various y = height - y tweaks before we pass y coordinates to OpenGL. Generally speaking though the handling of coordinate spaces in Cogl is a bit fragile. I guess partly because none of it was design to be, it just evolved from how Clutter defines its coordinates without much consideration or testing. I hope to improve this over a number of commits; starting here. This commit deals with the fact that offscreen draw buffers may be bound to textures but we don't "upload" the texture data upside down, and so if you texture from an offscreen draw buffer you need to manually flip the texture coordinates to get it the right way around. We now force offscreen rendering to be flipped upside down by tweaking the projection matrix right before we submit it to OpenGL to scale y by -1. The tweak is entirely hidden from the user such that if you call cogl_get_projection you will not see this scale.
2009-10-22 15:13:01 +00:00
cogl_matrix_init_identity (&_context->identity_matrix);
cogl_matrix_init_identity (&_context->y_flip_matrix);
cogl_matrix_scale (&_context->y_flip_matrix, 1, -1, 1);
_context->flushed_matrix_mode = COGL_MATRIX_MODELVIEW;
_context->texture_units =
g_array_new (FALSE, FALSE, sizeof (CoglTextureUnit));
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
/* See cogl-pipeline.c for more details about why we leave texture unit 1
* active by default... */
_context->active_texture_unit = 1;
GE (glActiveTexture (GL_TEXTURE1));
_context->legacy_fog_state.enabled = FALSE;
_context->opaque_color_pipeline = cogl_pipeline_new ();
_context->blended_color_pipeline = cogl_pipeline_new ();
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_context->texture_pipeline = cogl_pipeline_new ();
_context->fragment_header_buffer = g_string_new ("");
_context->fragment_source_buffer = g_string_new ("");
_context->source_stack = NULL;
_context->legacy_state_set = 0;
Bug 1172 - Disjoint paths and clip to path * clutter/cogl/cogl-path.h: * clutter/cogl/common/cogl-primitives.c: * clutter/cogl/common/cogl-primitives.h: * clutter/cogl/gl/cogl-primitives.c: * clutter/cogl/gles/cogl-primitives.c: Changed the semantics of cogl_path_move_to. Previously this always started a new path but now it instead starts a new disjoint sub path. The path isn't cleared until you call either cogl_path_stroke, cogl_path_fill or cogl_path_new. There are also cogl_path_stroke_preserve and cogl_path_fill_preserve functions. * clutter/cogl/gl/cogl-context.c: * clutter/cogl/gl/cogl-context.h: * clutter/cogl/gles/cogl-context.c: * clutter/cogl/gles/cogl-context.h: Convert the path nodes array to a GArray. * clutter/cogl/gl/cogl-texture.c: * clutter/cogl/gles/cogl-texture.c: Call cogl_clip_ensure * clutter/cogl/common/cogl-clip-stack.c: * clutter/cogl/common/cogl-clip-stack.h: Simplified the clip stack code quite a bit to make it more maintainable. Previously whenever you added a new clip it would go through a separate route to immediately intersect with the current clip and when you removed it again it would immediately rebuild the entire clip. Now when you add or remove a clip it doesn't do anything immediately but just sets a dirty flag instead. * clutter/cogl/gl/cogl.c: * clutter/cogl/gles/cogl.c: Taken away the code to intersect stencil clips when there is exactly one stencil bit. It won't work with path clips and I don't know of any platform that doesn't have eight or zero stencil bits. It needs at least three bits to intersect a path with an existing clip. cogl_features_init now just decides you don't have a stencil buffer at all if you have less than three bits. * clutter/cogl/cogl.h.in: New functions and documentation. * tests/interactive/test-clip.c: Replaced with a different test that lets you add and remove clips. The three different mouse buttons add clips in different shapes. This makes it easier to test multiple levels of clipping. * tests/interactive/test-cogl-primitives.c: Use cogl_path_stroke_preserve when using the same path again. * doc/reference/cogl/cogl-sections.txt: Document the new functions.
2008-12-04 13:45:09 +00:00
_context->default_gl_texture_2d_tex = COGL_INVALID_HANDLE;
_context->default_gl_texture_rect_tex = COGL_INVALID_HANDLE;
_context->journal = g_array_new (FALSE, FALSE, sizeof (CoglJournalEntry));
_context->logged_vertices = g_array_new (FALSE, FALSE, sizeof (GLfloat));
_context->journal_flush_attributes_array =
g_array_new (TRUE, FALSE, sizeof (CoglVertexAttribute *));
_context->journal_clip_bounds = NULL;
_context->polygon_vertices = g_array_new (FALSE, FALSE, sizeof (float));
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_context->current_pipeline = NULL;
_context->current_pipeline_changes_since_flush = 0;
_context->current_pipeline_skip_gl_color = FALSE;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_context->pipeline0_nodes =
CoglMaterial: Implements sparse materials design This is a complete overhaul of the data structures used to manage CoglMaterial state. We have these requirements that were aiming to meet: (Note: the references to "renderlists" correspond to the effort to support scenegraph level shuffling of Clutter actor primitives so we can minimize GPU state changes) Sparse State: We wanted a design that allows sparse descriptions of state so it scales well as we make CoglMaterial responsible for more and more state. It needs to scale well in terms of memory usage and the cost of operations we need to apply to materials such as comparing, copying and flushing their state. I.e. we would rather have these things scale by the number of real changes a material represents not by how much overall state CoglMaterial becomes responsible for. Cheap Copies: As we add support for renderlists in Clutter we will need to be able to get an immutable handle for a given material's current state so that we can retain a record of a primitive with its associated material without worrying that changes to the original material will invalidate that record. No more flush override options: We want to get rid of the flush overrides mechanism we currently use to deal with texture fallbacks, wrap mode changes and to handle the use of highlevel CoglTextures that need to be resolved into lowlevel textures before flushing the material state. The flush options structure has been expanding in size and the structure is logged with every journal entry so it is not an approach that scales well at all. It also makes flushing material state that much more complex. Weak Materials: Again for renderlists we need a way to create materials derived from other materials but without the strict requirement that modifications to the original material wont affect the derived ("weak") material. The only requirement is that its possible to later check if the original material has been changed. A summary of the new design: A CoglMaterial now basically represents a diff against its parent. Each material has a single parent and a mask of state that it changes. Each group of state (such as the blending state) has an "authority" which is found by walking up from a given material through its ancestors checking the difference mask until a match for that group is found. There is only one root node to the graph of all materials, which is the default material first created when Cogl is being initialized. All the groups of state are divided into two types, such that infrequently changed state belongs in a separate "BigState" structure that is only allocated and attached to a material when necessary. CoglMaterialLayers are another sparse structure. Like CoglMaterials they represent a diff against their parent and all the layers are part of another graph with the "default_layer_0" layer being the root node that Cogl creates during initialization. Copying a material is now basically just a case of slice allocating a CoglMaterial, setting the parent to be the source being copied and zeroing the mask of changes. Flush overrides should now be handled by simply relying on the cheapness of copying a material and making changes to it. (This will be done in a follow on commit) Weak material support will be added in a follow on commit.
2010-04-08 11:21:04 +00:00
g_array_sized_new (FALSE, FALSE, sizeof (CoglHandle), 20);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_context->pipeline1_nodes =
CoglMaterial: Implements sparse materials design This is a complete overhaul of the data structures used to manage CoglMaterial state. We have these requirements that were aiming to meet: (Note: the references to "renderlists" correspond to the effort to support scenegraph level shuffling of Clutter actor primitives so we can minimize GPU state changes) Sparse State: We wanted a design that allows sparse descriptions of state so it scales well as we make CoglMaterial responsible for more and more state. It needs to scale well in terms of memory usage and the cost of operations we need to apply to materials such as comparing, copying and flushing their state. I.e. we would rather have these things scale by the number of real changes a material represents not by how much overall state CoglMaterial becomes responsible for. Cheap Copies: As we add support for renderlists in Clutter we will need to be able to get an immutable handle for a given material's current state so that we can retain a record of a primitive with its associated material without worrying that changes to the original material will invalidate that record. No more flush override options: We want to get rid of the flush overrides mechanism we currently use to deal with texture fallbacks, wrap mode changes and to handle the use of highlevel CoglTextures that need to be resolved into lowlevel textures before flushing the material state. The flush options structure has been expanding in size and the structure is logged with every journal entry so it is not an approach that scales well at all. It also makes flushing material state that much more complex. Weak Materials: Again for renderlists we need a way to create materials derived from other materials but without the strict requirement that modifications to the original material wont affect the derived ("weak") material. The only requirement is that its possible to later check if the original material has been changed. A summary of the new design: A CoglMaterial now basically represents a diff against its parent. Each material has a single parent and a mask of state that it changes. Each group of state (such as the blending state) has an "authority" which is found by walking up from a given material through its ancestors checking the difference mask until a match for that group is found. There is only one root node to the graph of all materials, which is the default material first created when Cogl is being initialized. All the groups of state are divided into two types, such that infrequently changed state belongs in a separate "BigState" structure that is only allocated and attached to a material when necessary. CoglMaterialLayers are another sparse structure. Like CoglMaterials they represent a diff against their parent and all the layers are part of another graph with the "default_layer_0" layer being the root node that Cogl creates during initialization. Copying a material is now basically just a case of slice allocating a CoglMaterial, setting the parent to be the source being copied and zeroing the mask of changes. Flush overrides should now be handled by simply relying on the cheapness of copying a material and making changes to it. (This will be done in a follow on commit) Weak material support will be added in a follow on commit.
2010-04-08 11:21:04 +00:00
g_array_sized_new (FALSE, FALSE, sizeof (CoglHandle), 20);
_cogl_bitmask_init (&_context->texcoord_arrays_enabled);
_cogl_bitmask_init (&_context->temp_bitmask);
_cogl_bitmask_init (&_context->texcoord_arrays_to_disable);
_context->max_texture_units = -1;
_context->max_texture_image_units = -1;
_context->max_activateable_texture_units = -1;
_context->current_program = COGL_INVALID_HANDLE;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_context->current_use_program_type = COGL_PIPELINE_PROGRAM_TYPE_FIXED;
_context->current_gl_program = 0;
CoglMaterial: Implements sparse materials design This is a complete overhaul of the data structures used to manage CoglMaterial state. We have these requirements that were aiming to meet: (Note: the references to "renderlists" correspond to the effort to support scenegraph level shuffling of Clutter actor primitives so we can minimize GPU state changes) Sparse State: We wanted a design that allows sparse descriptions of state so it scales well as we make CoglMaterial responsible for more and more state. It needs to scale well in terms of memory usage and the cost of operations we need to apply to materials such as comparing, copying and flushing their state. I.e. we would rather have these things scale by the number of real changes a material represents not by how much overall state CoglMaterial becomes responsible for. Cheap Copies: As we add support for renderlists in Clutter we will need to be able to get an immutable handle for a given material's current state so that we can retain a record of a primitive with its associated material without worrying that changes to the original material will invalidate that record. No more flush override options: We want to get rid of the flush overrides mechanism we currently use to deal with texture fallbacks, wrap mode changes and to handle the use of highlevel CoglTextures that need to be resolved into lowlevel textures before flushing the material state. The flush options structure has been expanding in size and the structure is logged with every journal entry so it is not an approach that scales well at all. It also makes flushing material state that much more complex. Weak Materials: Again for renderlists we need a way to create materials derived from other materials but without the strict requirement that modifications to the original material wont affect the derived ("weak") material. The only requirement is that its possible to later check if the original material has been changed. A summary of the new design: A CoglMaterial now basically represents a diff against its parent. Each material has a single parent and a mask of state that it changes. Each group of state (such as the blending state) has an "authority" which is found by walking up from a given material through its ancestors checking the difference mask until a match for that group is found. There is only one root node to the graph of all materials, which is the default material first created when Cogl is being initialized. All the groups of state are divided into two types, such that infrequently changed state belongs in a separate "BigState" structure that is only allocated and attached to a material when necessary. CoglMaterialLayers are another sparse structure. Like CoglMaterials they represent a diff against their parent and all the layers are part of another graph with the "default_layer_0" layer being the root node that Cogl creates during initialization. Copying a material is now basically just a case of slice allocating a CoglMaterial, setting the parent to be the source being copied and zeroing the mask of changes. Flush overrides should now be handled by simply relying on the cheapness of copying a material and making changes to it. (This will be done in a follow on commit) Weak material support will be added in a follow on commit.
2010-04-08 11:21:04 +00:00
_context->gl_blend_enable_cache = FALSE;
_context->depth_test_enabled_cache = FALSE;
_context->depth_test_function_cache = COGL_DEPTH_TEST_FUNCTION_LESS;
_context->depth_writing_enabled_cache = TRUE;
_context->depth_range_near_cache = 0;
_context->depth_range_far_cache = 1;
_context->point_size_cache = 1.0f;
_context->legacy_depth_test_enabled = FALSE;
#ifdef HAVE_COGL_GL
_context->arbfp_cache = g_hash_table_new (_cogl_pipeline_arbfp_hash,
_cogl_pipeline_arbfp_equal);
#endif
for (i = 0; i < COGL_BUFFER_BIND_TARGET_COUNT; i++)
_context->current_buffer[i] = NULL;
_context->framebuffer_stack = _cogl_create_framebuffer_stack ();
_context->current_clip_stack_valid = FALSE;
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 13:34:34 +00:00
window_buffer = _cogl_onscreen_new ();
cogl_set_framebuffer (window_buffer);
/* XXX: the deprecated _cogl_set_draw_buffer API expects to
* find the window buffer here... */
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 13:34:34 +00:00
_context->window_buffer = window_buffer;
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 13:34:34 +00:00
_context->dirty_bound_framebuffer = TRUE;
_context->dirty_gl_viewport = TRUE;
_context->current_path = cogl2_path_new ();
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_context->stencil_pipeline = cogl_pipeline_new ();
GLES 2 backend * clutter/eglx/clutter-stage-egl.h: * clutter/eglx/clutter-egl-headers.h: * clutter/eglx/clutter-backend-egl.h: * clutter/eglx/Makefile.am: Include the GLES and EGL headers via clutter-egl-headers.h so that the right version can be used depending on whether the GLES 2 wrapper is being used. * configure.ac: Added an automake conditional for whether the GLES 2 wrapper should be used. * clutter/eglx/clutter-stage-egl.c (clutter_stage_egl_realize): Remove the call to glGetIntegerv to get the max texture size. It was being called before the GL context was bound so it didn't work anyway and it was causing trouble for the GLES 2 simulator. * clutter/cogl/gles/stringify.sh: Shell script to convert the shaders into a C string. * clutter/cogl/gles/cogl-gles2-wrapper.h: * clutter/cogl/gles/cogl-gles2-wrapper.c: Wrappers for most of the missing GL functions in GLES 2. * clutter/cogl/gles/cogl-fixed-fragment-shader.glsl: * clutter/cogl/gles/cogl-fixed-vertex-shader.glsl: New shaders for GLES 2 * clutter/cogl/gles/cogl-defines.h.in: Use the @CLUTTER_GL_HEADER@ macro instead of always using the GLES 1 header. * clutter/cogl/gles/cogl-context.h (CoglContext): Include a field for the state of the GLES 2 wrapper. * clutter/cogl/gles/cogl-texture.c: * clutter/cogl/gles/cogl-primitives.c: * clutter/cogl/gles/cogl.c: Use wrapped versions of the GL functions where neccessary. * clutter/cogl/gles/Makefile.am: Add sources for the GLES 2 wrapper and an extra build step to put the GLSL files into a C string whenever the files change.
2008-05-27 17:42:50 +00:00
_context->in_begin_gl_block = FALSE;
_context->quad_buffer_indices_byte = COGL_INVALID_HANDLE;
_context->quad_buffer_indices = COGL_INVALID_HANDLE;
_context->quad_buffer_indices_len = 0;
_context->rectangle_byte_indices = NULL;
_context->rectangle_short_indices = NULL;
_context->rectangle_short_indices_len = 0;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
_context->texture_download_pipeline = COGL_INVALID_HANDLE;
/* The default for GL_ALPHA_TEST is to always pass which is equivalent to
* the test being disabled therefore we assume that for all drivers there
* will be no performance impact if we always leave the test enabled which
* makes things a bit simpler for us. */
GE (glEnable (GL_ALPHA_TEST));
/* Create default textures used for fall backs */
_context->default_gl_texture_2d_tex =
cogl_texture_new_from_data (1, /* width */
1, /* height */
COGL_TEXTURE_NO_SLICING,
COGL_PIXEL_FORMAT_RGBA_8888_PRE, /* data format */
/* internal format */
COGL_PIXEL_FORMAT_RGBA_8888_PRE,
0, /* auto calc row stride */
default_texture_data);
_context->default_gl_texture_rect_tex =
cogl_texture_new_from_data (1, /* width */
1, /* height */
COGL_TEXTURE_NO_SLICING,
COGL_PIXEL_FORMAT_RGBA_8888_PRE, /* data format */
/* internal format */
COGL_PIXEL_FORMAT_RGBA_8888_PRE,
0, /* auto calc row stride */
default_texture_data);
cogl_push_source (_context->opaque_color_pipeline);
_cogl_pipeline_flush_gl_state (_context->opaque_color_pipeline, FALSE, 0);
_cogl_enable (enable_flags);
_cogl_flush_face_winding ();
_context->atlas = NULL;
/* As far as I can tell, GL_POINT_SPRITE doesn't have any effect
unless GL_COORD_REPLACE is enabled for an individual
layer. Therefore it seems like it should be ok to just leave it
enabled all the time instead of having to have a set property on
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
each pipeline to track whether any layers have point sprite
coords enabled */
if (cogl_features_available (COGL_FEATURE_POINT_SPRITE))
GE (glEnable (GL_POINT_SPRITE));
return TRUE;
}
void
_cogl_destroy_context (void)
{
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 13:34:34 +00:00
if (_context == NULL)
return;
_cogl_destroy_context_winsys (_context);
_cogl_destroy_texture_units ();
_cogl_free_framebuffer_stack (_context->framebuffer_stack);
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 13:34:34 +00:00
if (_context->current_path)
cogl_handle_unref (_context->current_path);
Bug 1172 - Disjoint paths and clip to path * clutter/cogl/cogl-path.h: * clutter/cogl/common/cogl-primitives.c: * clutter/cogl/common/cogl-primitives.h: * clutter/cogl/gl/cogl-primitives.c: * clutter/cogl/gles/cogl-primitives.c: Changed the semantics of cogl_path_move_to. Previously this always started a new path but now it instead starts a new disjoint sub path. The path isn't cleared until you call either cogl_path_stroke, cogl_path_fill or cogl_path_new. There are also cogl_path_stroke_preserve and cogl_path_fill_preserve functions. * clutter/cogl/gl/cogl-context.c: * clutter/cogl/gl/cogl-context.h: * clutter/cogl/gles/cogl-context.c: * clutter/cogl/gles/cogl-context.h: Convert the path nodes array to a GArray. * clutter/cogl/gl/cogl-texture.c: * clutter/cogl/gles/cogl-texture.c: Call cogl_clip_ensure * clutter/cogl/common/cogl-clip-stack.c: * clutter/cogl/common/cogl-clip-stack.h: Simplified the clip stack code quite a bit to make it more maintainable. Previously whenever you added a new clip it would go through a separate route to immediately intersect with the current clip and when you removed it again it would immediately rebuild the entire clip. Now when you add or remove a clip it doesn't do anything immediately but just sets a dirty flag instead. * clutter/cogl/gl/cogl.c: * clutter/cogl/gles/cogl.c: Taken away the code to intersect stencil clips when there is exactly one stencil bit. It won't work with path clips and I don't know of any platform that doesn't have eight or zero stencil bits. It needs at least three bits to intersect a path with an existing clip. cogl_features_init now just decides you don't have a stencil buffer at all if you have less than three bits. * clutter/cogl/cogl.h.in: New functions and documentation. * tests/interactive/test-clip.c: Replaced with a different test that lets you add and remove clips. The three different mouse buttons add clips in different shapes. This makes it easier to test multiple levels of clipping. * tests/interactive/test-cogl-primitives.c: Use cogl_path_stroke_preserve when using the same path again. * doc/reference/cogl/cogl-sections.txt: Document the new functions.
2008-12-04 13:45:09 +00:00
if (_context->default_gl_texture_2d_tex)
cogl_handle_unref (_context->default_gl_texture_2d_tex);
if (_context->default_gl_texture_rect_tex)
cogl_handle_unref (_context->default_gl_texture_rect_tex);
if (_context->opaque_color_pipeline)
cogl_handle_unref (_context->opaque_color_pipeline);
if (_context->blended_color_pipeline)
cogl_handle_unref (_context->blended_color_pipeline);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
if (_context->texture_pipeline)
cogl_handle_unref (_context->texture_pipeline);
if (_context->journal)
g_array_free (_context->journal, TRUE);
if (_context->logged_vertices)
g_array_free (_context->logged_vertices, TRUE);
if (_context->journal_flush_attributes_array)
g_array_free (_context->journal_flush_attributes_array, TRUE);
if (_context->journal_clip_bounds)
g_array_free (_context->journal_clip_bounds, TRUE);
if (_context->polygon_vertices)
g_array_free (_context->polygon_vertices, TRUE);
if (_context->quad_buffer_indices_byte)
cogl_handle_unref (_context->quad_buffer_indices_byte);
if (_context->quad_buffer_indices)
cogl_handle_unref (_context->quad_buffer_indices);
if (_context->rectangle_byte_indices)
cogl_object_unref (_context->rectangle_byte_indices);
if (_context->rectangle_short_indices)
cogl_object_unref (_context->rectangle_short_indices);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 17:54:57 +00:00
if (_context->default_pipeline)
cogl_handle_unref (_context->default_pipeline);
CoglMaterial: Implements sparse materials design This is a complete overhaul of the data structures used to manage CoglMaterial state. We have these requirements that were aiming to meet: (Note: the references to "renderlists" correspond to the effort to support scenegraph level shuffling of Clutter actor primitives so we can minimize GPU state changes) Sparse State: We wanted a design that allows sparse descriptions of state so it scales well as we make CoglMaterial responsible for more and more state. It needs to scale well in terms of memory usage and the cost of operations we need to apply to materials such as comparing, copying and flushing their state. I.e. we would rather have these things scale by the number of real changes a material represents not by how much overall state CoglMaterial becomes responsible for. Cheap Copies: As we add support for renderlists in Clutter we will need to be able to get an immutable handle for a given material's current state so that we can retain a record of a primitive with its associated material without worrying that changes to the original material will invalidate that record. No more flush override options: We want to get rid of the flush overrides mechanism we currently use to deal with texture fallbacks, wrap mode changes and to handle the use of highlevel CoglTextures that need to be resolved into lowlevel textures before flushing the material state. The flush options structure has been expanding in size and the structure is logged with every journal entry so it is not an approach that scales well at all. It also makes flushing material state that much more complex. Weak Materials: Again for renderlists we need a way to create materials derived from other materials but without the strict requirement that modifications to the original material wont affect the derived ("weak") material. The only requirement is that its possible to later check if the original material has been changed. A summary of the new design: A CoglMaterial now basically represents a diff against its parent. Each material has a single parent and a mask of state that it changes. Each group of state (such as the blending state) has an "authority" which is found by walking up from a given material through its ancestors checking the difference mask until a match for that group is found. There is only one root node to the graph of all materials, which is the default material first created when Cogl is being initialized. All the groups of state are divided into two types, such that infrequently changed state belongs in a separate "BigState" structure that is only allocated and attached to a material when necessary. CoglMaterialLayers are another sparse structure. Like CoglMaterials they represent a diff against their parent and all the layers are part of another graph with the "default_layer_0" layer being the root node that Cogl creates during initialization. Copying a material is now basically just a case of slice allocating a CoglMaterial, setting the parent to be the source being copied and zeroing the mask of changes. Flush overrides should now be handled by simply relying on the cheapness of copying a material and making changes to it. (This will be done in a follow on commit) Weak material support will be added in a follow on commit.
2010-04-08 11:21:04 +00:00
if (_context->dummy_layer_dependant)
cogl_handle_unref (_context->dummy_layer_dependant);
if (_context->default_layer_n)
cogl_handle_unref (_context->default_layer_n);
if (_context->default_layer_0)
cogl_handle_unref (_context->default_layer_0);
if (_context->current_clip_stack_valid)
_cogl_clip_stack_unref (_context->current_clip_stack);
if (_context->atlas)
_cogl_atlas_free (_context->atlas);
_cogl_bitmask_destroy (&_context->texcoord_arrays_enabled);
_cogl_bitmask_destroy (&_context->temp_bitmask);
_cogl_bitmask_destroy (&_context->texcoord_arrays_to_disable);
g_slist_free (_context->texture_types);
g_slist_free (_context->buffer_types);
#ifdef HAVE_COGL_GL
g_hash_table_unref (_context->arbfp_cache);
#endif
g_free (_context);
}
CoglContext *
_cogl_context_get_default (void)
{
/* Create if doesn't exist yet */
if (_context == NULL)
cogl_create_context ();
return _context;
}
/**
* _cogl_set_indirect_context:
* @indirect: TRUE if GL context is indirect
*
* Advises COGL that the GL context is indirect (commands are sent
* over a socket). COGL uses this information to try to avoid
* round-trips in its use of GL, for example.
*
* This function cannot be called "on the fly," only before COGL
* initializes.
*/
void
_cogl_set_indirect_context (gboolean indirect)
{
/* we get called multiple times if someone creates
* more than the default stage
*/
if (_context != NULL)
{
if (indirect != _context->indirect)
g_warning ("Right now all stages will be treated as "
"either direct or indirect, ignoring attempt "
"to change to indirect=%d", indirect);
return;
}
gl_is_indirect = indirect;
}