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

455 lines
13 KiB
C
Raw Normal View History

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 13:54:57 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2010 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
* Authors:
* Robert Bragg <robert@linux.intel.com>
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <cogl-material-compat.h>
#include <cogl-pipeline.h>
#include <cogl-pipeline-private.h>
#include <cogl-types.h>
#include <cogl-matrix.h>
cogl: rename cogl-context.h cogl-context-private.h Since we plan to add public cogl_context_* API we need to rename the current cogl-context.h which contains private member details.
2010-11-04 18:25:52 -04:00
#include <cogl-context-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 13:54:57 -04:00
CoglMaterial *
cogl_material_new (void)
{
Adds a context arg to cogl_pipeline_new() As we move towards Cogl 2.0 we are aiming to remove the need for a default global CoglContext and so everything should be explicitly related to a context somehow. CoglPipelines are top level objects and so this patch adds a context argument to cogl_pipeline_new(). Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-18 11:03:10 -05:00
_COGL_GET_CONTEXT(ctx, NULL);
return COGL_MATERIAL (cogl_pipeline_new (ctx));
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 13:54:57 -04:00
}
CoglMaterial *
cogl_material_copy (CoglMaterial *source)
{
return COGL_MATERIAL (cogl_pipeline_copy (COGL_PIPELINE (source)));
}
CoglHandle
cogl_material_ref (CoglHandle handle)
{
return cogl_object_ref (handle);
}
void
cogl_material_unref (CoglHandle handle)
{
cogl_object_unref (handle);
}
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
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 13:54:57 -04:00
cogl_is_material (CoglHandle handle)
{
return cogl_is_pipeline (handle);
}
void
cogl_material_set_color (CoglMaterial *material,
const CoglColor *color)
{
cogl_pipeline_set_color (COGL_PIPELINE (material), color);
}
void
cogl_material_set_color4ub (CoglMaterial *material,
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
uint8_t red,
uint8_t green,
uint8_t blue,
uint8_t alpha)
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 13:54:57 -04:00
{
cogl_pipeline_set_color4ub (COGL_PIPELINE (material),
red, green, blue, alpha);
}
void
cogl_material_set_color4f (CoglMaterial *material,
float red,
float green,
float blue,
float alpha)
{
cogl_pipeline_set_color4f (COGL_PIPELINE (material),
red, green, blue, alpha);
}
void
cogl_material_get_color (CoglMaterial *material,
CoglColor *color)
{
cogl_pipeline_get_color (COGL_PIPELINE (material), color);
}
void
cogl_material_set_ambient (CoglMaterial *material,
const CoglColor *ambient)
{
cogl_pipeline_set_ambient (COGL_PIPELINE (material), ambient);
}
void
cogl_material_get_ambient (CoglMaterial *material,
CoglColor *ambient)
{
cogl_pipeline_get_ambient (COGL_PIPELINE (material), ambient);
}
void
cogl_material_set_diffuse (CoglMaterial *material,
const CoglColor *diffuse)
{
cogl_pipeline_set_diffuse (COGL_PIPELINE (material), diffuse);
}
void
cogl_material_get_diffuse (CoglMaterial *material,
CoglColor *diffuse)
{
cogl_pipeline_get_diffuse (COGL_PIPELINE (material), diffuse);
}
void
cogl_material_set_ambient_and_diffuse (CoglMaterial *material,
const CoglColor *color)
{
cogl_pipeline_set_ambient_and_diffuse (COGL_PIPELINE (material), color);
}
void
cogl_material_set_specular (CoglMaterial *material,
const CoglColor *specular)
{
cogl_pipeline_set_specular (COGL_PIPELINE (material), specular);
}
void
cogl_material_get_specular (CoglMaterial *material,
CoglColor *specular)
{
cogl_pipeline_get_specular (COGL_PIPELINE (material), specular);
}
void
cogl_material_set_shininess (CoglMaterial *material,
float shininess)
{
cogl_pipeline_set_shininess (COGL_PIPELINE (material), shininess);
}
float
cogl_material_get_shininess (CoglMaterial *material)
{
return cogl_pipeline_get_shininess (COGL_PIPELINE (material));
}
void
cogl_material_set_emission (CoglMaterial *material,
const CoglColor *emission)
{
cogl_pipeline_set_emission (COGL_PIPELINE (material), emission);
}
void
cogl_material_get_emission (CoglMaterial *material,
CoglColor *emission)
{
cogl_pipeline_get_emission (COGL_PIPELINE (material), emission);
}
void
cogl_material_set_alpha_test_function (CoglMaterial *material,
CoglMaterialAlphaFunc alpha_func,
float alpha_reference)
{
cogl_pipeline_set_alpha_test_function (COGL_PIPELINE (material),
alpha_func,
alpha_reference);
}
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
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 13:54:57 -04:00
cogl_material_set_blend (CoglMaterial *material,
const char *blend_string,
GError **error)
{
return cogl_pipeline_set_blend (COGL_PIPELINE (material),
blend_string,
error);
}
void
cogl_material_set_blend_constant (CoglMaterial *material,
const CoglColor *constant_color)
{
cogl_pipeline_set_blend_constant (COGL_PIPELINE (material), constant_color);
}
void
cogl_material_set_point_size (CoglMaterial *material,
float point_size)
{
cogl_pipeline_set_point_size (COGL_PIPELINE (material), point_size);
}
float
cogl_material_get_point_size (CoglMaterial *material)
{
return cogl_pipeline_get_point_size (COGL_PIPELINE (material));
}
CoglHandle
cogl_material_get_user_program (CoglMaterial *material)
{
return cogl_pipeline_get_user_program (COGL_PIPELINE (material));
}
void
cogl_material_set_user_program (CoglMaterial *material,
CoglHandle program)
{
cogl_pipeline_set_user_program (COGL_PIPELINE (material), program);
}
void
cogl_material_set_layer (CoglMaterial *material,
int layer_index,
CoglHandle texture)
{
cogl_pipeline_set_layer_texture (COGL_PIPELINE (material),
layer_index, texture);
}
void
cogl_material_remove_layer (CoglMaterial *material,
int layer_index)
{
cogl_pipeline_remove_layer (COGL_PIPELINE (material), layer_index);
}
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
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 13:54:57 -04:00
cogl_material_set_layer_combine (CoglMaterial *material,
int layer_index,
const char *blend_string,
GError **error)
{
return cogl_pipeline_set_layer_combine (COGL_PIPELINE (material),
layer_index,
blend_string,
error);
}
void
cogl_material_set_layer_combine_constant (CoglMaterial *material,
int layer_index,
const CoglColor *constant)
{
cogl_pipeline_set_layer_combine_constant (COGL_PIPELINE (material),
layer_index,
constant);
}
void
cogl_material_set_layer_matrix (CoglMaterial *material,
int layer_index,
const CoglMatrix *matrix)
{
cogl_pipeline_set_layer_matrix (COGL_PIPELINE (material),
layer_index, matrix);
}
Remove G_CONST_RETURN It is going to be deprecated by GLib, see bug: https://bugzilla.gnome.org/show_bug.cgi?id=644611
2011-06-09 11:21:15 -04:00
const GList *
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 13:54:57 -04:00
cogl_material_get_layers (CoglMaterial *material)
{
return _cogl_pipeline_get_layers (COGL_PIPELINE (material));
}
int
cogl_material_get_n_layers (CoglMaterial *material)
{
return cogl_pipeline_get_n_layers (COGL_PIPELINE (material));
}
CoglMaterialLayerType
cogl_material_layer_get_type (CoglMaterialLayer *layer)
{
return COGL_MATERIAL_LAYER_TYPE_TEXTURE;
}
CoglHandle
cogl_material_layer_get_texture (CoglMaterialLayer *layer)
{
return _cogl_pipeline_layer_get_texture (COGL_PIPELINE_LAYER (layer));
}
CoglMaterialFilter
cogl_material_layer_get_min_filter (CoglMaterialLayer *layer)
{
return _cogl_pipeline_layer_get_min_filter (COGL_PIPELINE_LAYER (layer));
}
CoglMaterialFilter
cogl_material_layer_get_mag_filter (CoglMaterialLayer *layer)
{
return _cogl_pipeline_layer_get_mag_filter (COGL_PIPELINE_LAYER (layer));
}
void
cogl_material_set_layer_filters (CoglMaterial *material,
int layer_index,
CoglMaterialFilter min_filter,
CoglMaterialFilter mag_filter)
{
cogl_pipeline_set_layer_filters (COGL_PIPELINE (material),
layer_index,
min_filter,
mag_filter);
}
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
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 13:54:57 -04:00
cogl_material_set_layer_point_sprite_coords_enabled (CoglMaterial *material,
int layer_index,
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool enable,
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 13:54:57 -04:00
GError **error)
{
CoglPipeline *pipeline = COGL_PIPELINE (material);
return cogl_pipeline_set_layer_point_sprite_coords_enabled (pipeline,
layer_index,
enable,
error);
}
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
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 13:54:57 -04:00
cogl_material_get_layer_point_sprite_coords_enabled (CoglMaterial *material,
int layer_index)
{
CoglPipeline *pipeline = COGL_PIPELINE (material);
return cogl_pipeline_get_layer_point_sprite_coords_enabled (pipeline,
layer_index);
}
CoglMaterialWrapMode
cogl_material_get_layer_wrap_mode_s (CoglMaterial *material,
int layer_index)
{
return cogl_pipeline_get_layer_wrap_mode_s (COGL_PIPELINE (material),
layer_index);
}
void
cogl_material_set_layer_wrap_mode_s (CoglMaterial *material,
int layer_index,
CoglMaterialWrapMode mode)
{
cogl_pipeline_set_layer_wrap_mode_s (COGL_PIPELINE (material), layer_index,
mode);
}
CoglMaterialWrapMode
cogl_material_get_layer_wrap_mode_t (CoglMaterial *material,
int layer_index)
{
return cogl_pipeline_get_layer_wrap_mode_t (COGL_PIPELINE (material),
layer_index);
}
void
cogl_material_set_layer_wrap_mode_t (CoglMaterial *material,
int layer_index,
CoglMaterialWrapMode mode)
{
cogl_pipeline_set_layer_wrap_mode_t (COGL_PIPELINE (material), layer_index,
mode);
}
CoglMaterialWrapMode
cogl_material_get_layer_wrap_mode_p (CoglMaterial *material,
int layer_index)
{
return cogl_pipeline_get_layer_wrap_mode_p (COGL_PIPELINE (material),
layer_index);
}
void
cogl_material_set_layer_wrap_mode_p (CoglMaterial *material,
int layer_index,
CoglMaterialWrapMode mode)
{
cogl_pipeline_set_layer_wrap_mode_p (COGL_PIPELINE (material), layer_index,
mode);
}
void
cogl_material_set_layer_wrap_mode (CoglMaterial *material,
int layer_index,
CoglMaterialWrapMode mode)
{
cogl_pipeline_set_layer_wrap_mode (COGL_PIPELINE (material), layer_index,
mode);
}
CoglMaterialWrapMode
cogl_material_layer_get_wrap_mode_s (CoglMaterialLayer *layer)
{
return _cogl_pipeline_layer_get_wrap_mode_s (COGL_PIPELINE_LAYER (layer));
}
CoglMaterialWrapMode
cogl_material_layer_get_wrap_mode_t (CoglMaterialLayer *layer)
{
return _cogl_pipeline_layer_get_wrap_mode_t (COGL_PIPELINE_LAYER (layer));
}
CoglMaterialWrapMode
cogl_material_layer_get_wrap_mode_p (CoglMaterialLayer *layer)
{
return _cogl_pipeline_layer_get_wrap_mode_p (COGL_PIPELINE_LAYER (layer));
}
void
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
cogl_material_foreach_layer (CoglMaterial *material,
CoglMaterialLayerCallback callback,
void *user_data)
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 13:54:57 -04:00
{
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
cogl_pipeline_foreach_layer (COGL_PIPELINE (material),
(CoglPipelineLayerCallback)callback, user_data);
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 13:54:57 -04:00
}
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
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
cogl_material_set_depth_state (CoglMaterial *material,
const CoglDepthState *state,
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 13:54:57 -04:00
GError **error)
{
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
return cogl_pipeline_set_depth_state (COGL_PIPELINE (material),
state, error);
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 13:54:57 -04:00
}
void
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
cogl_material_get_depth_state (CoglMaterial *material,
CoglDepthState *state_out)
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 13:54:57 -04:00
{
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
cogl_pipeline_get_depth_state (COGL_PIPELINE (material), state_out);
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 13:54:57 -04:00
}
Reference in New Issue Copy Permalink