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

1406 lines
47 KiB
C
Raw Normal View History

material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2008,2009,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.h"
cogl: don't include cogl-debug.h in cogl.h or install cogl-debug.h is an internal header so it shouldn't have been included by cogl.h and the header shouldn't be installed either.
2010-07-25 16:36:41 -04:00
#include "cogl-debug.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
#include "cogl-pipeline-opengl-private.h"
#include "cogl-pipeline-private.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"
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#include "cogl-texture-private.h"
framebuffer: split out CoglOnscreen code This factors out the CoglOnscreen code from cogl-framebuffer.c so we now have cogl-onscreen.c, cogl-onscreen.h and cogl-onscreen-private.h. Notably some of the functions pulled out are currently namespaced as cogl_framebuffer but we know we are planning on renaming them to be in the cogl_onscreen namespace; such as cogl_framebuffer_swap_buffers(). Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 16:31:04 -04:00
#include "cogl-framebuffer-private.h"
build: Start moving to a non-recursive layout *** WARNING: THIS COMMIT CHANGES THE BUILD *** Do not recurse into the backend directories to build private, internal libraries. We only recurse from clutter/ into the cogl sub-directory; from there, we don't recurse any further. All the backend-specific code in Cogl and Clutter is compiled conditionally depending on the macros defined by the configure script. We still recurse from the top-level directory into doc, clutter and tests, because gtk-doc and tests do not deal nicely with non-recursive layouts. This change makes Clutter compile slightly faster, and cleans up the build system, especially when dealing with introspection data. Ideally, we also want to make Cogl part of the top-level build, so that we can finally drop the sed trick to change the shared library from the GIR before compiling it. Currently disabled: ‣ OSX backend ‣ Fruity backend Currently enabled but untested: ‣ EGL backend ‣ Windows backend
2010-09-13 06:30:30 -04:00
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
/* This is needed to set the color attribute on GLES2 */
#ifdef HAVE_COGL_GLES2
#include "cogl-pipeline-progend-glsl-private.h"
#endif
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#include <glib.h>
#include <string.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
* GL/GLES compatability defines for pipeline thingies:
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*/
/* These aren't defined in the GLES headers */
#ifndef GL_POINT_SPRITE
#define GL_POINT_SPRITE 0x8861
#endif
#ifndef GL_COORD_REPLACE
#define GL_COORD_REPLACE 0x8862
#endif
#ifndef GL_CLAMP_TO_BORDER
#define GL_CLAMP_TO_BORDER 0x812d
#endif
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
static void
texture_unit_init (CoglTextureUnit *unit, int index_)
{
unit->index = index_;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->enabled_gl_target = 0;
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->gl_texture = 0;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->gl_target = 0;
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->is_foreign = FALSE;
unit->dirty_gl_texture = FALSE;
unit->matrix_stack = _cogl_matrix_stack_new ();
unit->layer = NULL;
unit->layer_changes_since_flush = 0;
unit->texture_storage_changed = FALSE;
}
static void
texture_unit_free (CoglTextureUnit *unit)
{
if (unit->layer)
cogl_object_unref (unit->layer);
cogl-matrix-stack: Convert to be a CoglObject We will want to use ref-counting on the CoglMatrixStack so it might as well be a CoglObject.
2010-12-10 11:06:16 -05:00
cogl_object_unref (unit->matrix_stack);
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
}
CoglTextureUnit *
_cogl_get_texture_unit (int index_)
{
_COGL_GET_CONTEXT (ctx, NULL);
if (ctx->texture_units->len < (index_ + 1))
{
int i;
int prev_len = ctx->texture_units->len;
ctx->texture_units = g_array_set_size (ctx->texture_units, index_ + 1);
for (i = prev_len; i <= index_; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
texture_unit_init (unit, i);
}
}
return &g_array_index (ctx->texture_units, CoglTextureUnit, index_);
}
void
_cogl_destroy_texture_units (void)
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
texture_unit_free (unit);
}
g_array_free (ctx->texture_units, TRUE);
}
void
_cogl_set_active_texture_unit (int unit_index)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (ctx->active_texture_unit != unit_index)
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glActiveTexture (GL_TEXTURE0 + unit_index));
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
ctx->active_texture_unit = unit_index;
}
}
/* Note: _cogl_bind_gl_texture_transient conceptually has slightly
* different semantics to OpenGL's glBindTexture because Cogl never
* cares about tracking multiple textures bound to different targets
* on the same texture unit.
*
* glBindTexture lets you bind multiple textures to a single texture
* unit if they are bound to different targets. So it does something
* like:
* unit->current_texture[target] = texture;
*
* Cogl only lets you associate one texture with the currently active
* texture unit, so the target is basically a redundant parameter
* that's implicitly set on that texture.
*
* Technically this is just a thin wrapper around glBindTexture so
* actually it does have the GL semantics but it seems worth
* mentioning the conceptual difference in case anyone wonders why we
* don't associate the gl_texture with a gl_target in the
* CoglTextureUnit.
*/
void
_cogl_bind_gl_texture_transient (GLenum gl_target,
GLuint gl_texture,
gboolean is_foreign)
{
CoglTextureUnit *unit;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* We choose to always make texture unit 1 active for transient
* binds so that in the common case where multitexturing isn't used
* we can simply ignore the state of this texture unit. Notably we
* didn't use a large texture unit (.e.g. (GL_MAX_TEXTURE_UNITS - 1)
* in case the driver doesn't have a sparse data structure for
* texture units.
*/
_cogl_set_active_texture_unit (1);
unit = _cogl_get_texture_unit (1);
/* NB: If we have previously bound a foreign texture to this texture
* unit we don't know if that texture has since been deleted and we
* are seeing the texture name recycled */
if (unit->gl_texture == gl_texture &&
!unit->dirty_gl_texture &&
!unit->is_foreign)
return;
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindTexture (gl_target, gl_texture));
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->dirty_gl_texture = TRUE;
unit->is_foreign = is_foreign;
}
void
_cogl_delete_gl_texture (GLuint gl_texture)
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
if (unit->gl_texture == gl_texture)
{
unit->gl_texture = 0;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->gl_target = 0;
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->dirty_gl_texture = FALSE;
}
}
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDeleteTextures (1, &gl_texture));
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
}
/* Whenever the underlying GL texture storage of a CoglTexture is
* changed (e.g. due to migration out of a texture atlas) then we are
* notified. This lets us ensure that we reflush that texture's state
material: don't dereference layer->texture directly In _cogl_material_texture_storage_change_notify we were potentially dereferencing layer->texture without checking first that it is the authority of texture state. We now use _cogl_material_layer_get_texture() instead.
2010-08-08 08:05:40 -04:00
* if it is reused again with the same texture unit.
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
*/
void
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
_cogl_pipeline_texture_storage_change_notify (CoglTexture *texture)
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
if (unit->layer &&
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_layer_get_texture (unit->layer) == texture)
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->texture_storage_changed = TRUE;
/* NB: the texture may be bound to multiple texture units so
* we continue to check the rest */
}
}
cogl-pipeline-opengl: #ifdef out set_glsl_program for GLES 1.1 glUseProgram is not available under GLES 1.1 so it was breaking the build. http://bugzilla.clutter-project.org/show_bug.cgi?id=2516
2011-01-17 07:20:06 -05:00
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
static void
set_glsl_program (GLuint gl_program)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (ctx->current_gl_program != gl_program)
{
GLenum gl_error;
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
while ((gl_error = ctx->glGetError ()) != GL_NO_ERROR)
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
;
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
ctx->glUseProgram (gl_program);
if (ctx->glGetError () == GL_NO_ERROR)
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
ctx->current_gl_program = gl_program;
else
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE( ctx, glUseProgram (0) );
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
ctx->current_gl_program = 0;
}
}
}
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
void
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
_cogl_use_fragment_program (GLuint gl_program, CoglPipelineProgramType type)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Avoid mixing declarations and code Mixing declarations and code causes problems for MSVC as it is a C99 feature so we should try to avoid it.
2010-10-25 08:08:52 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
/* If we're changing program type... */
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
if (type != ctx->current_fragment_program_type)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
/* ... disable the old type */
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
switch (ctx->current_fragment_program_type)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
/* If the program contains a vertex shader then we shouldn't
disable it */
if (ctx->current_vertex_program_type !=
COGL_PIPELINE_PROGRAM_TYPE_GLSL)
set_glsl_program (0);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
break;
cogl-program: gles2: bind programs lazily as for GL This makes the gles2 cogl_program_use consistent with the GL version by not binding the program immediately and instead leaving it to cogl-material.c to bind the program when actually drawing something.
2010-07-23 05:12:39 -04:00
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
case COGL_PIPELINE_PROGRAM_TYPE_ARBFP:
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
#ifdef HAVE_COGL_GL
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE( ctx, glDisable (GL_FRAGMENT_PROGRAM_ARB) );
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#endif
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
break;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
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
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
/* don't need to to anything */
break;
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
/* ... and enable the new type */
switch (type)
{
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
case COGL_PIPELINE_PROGRAM_TYPE_ARBFP:
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
#ifdef HAVE_COGL_GL
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE( ctx, glEnable (GL_FRAGMENT_PROGRAM_ARB) );
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#endif
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
break;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
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
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
/* don't need to to anything */
break;
}
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
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
if (type == COGL_PIPELINE_PROGRAM_TYPE_GLSL)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#ifdef COGL_PIPELINE_FRAGEND_GLSL
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
set_glsl_program (gl_program);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#else
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
g_warning ("Unexpected use of GLSL fragend!");
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#endif /* COGL_PIPELINE_FRAGEND_GLSL */
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#ifndef COGL_PIPELINE_FRAGEND_ARBFP
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
else if (type == COGL_PIPELINE_PROGRAM_TYPE_ARBFP)
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
g_warning ("Unexpected use of ARBFP fragend!");
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#endif /* COGL_PIPELINE_FRAGEND_ARBFP */
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
ctx->current_fragment_program_type = type;
}
void
_cogl_use_vertex_program (GLuint gl_program, CoglPipelineProgramType type)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* If we're changing program type... */
if (type != ctx->current_vertex_program_type)
{
/* ... disable the old type */
switch (ctx->current_vertex_program_type)
{
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
/* If the program contains a fragment shader then we shouldn't
disable it */
if (ctx->current_fragment_program_type !=
COGL_PIPELINE_PROGRAM_TYPE_GLSL)
set_glsl_program (0);
break;
case COGL_PIPELINE_PROGRAM_TYPE_ARBFP:
/* It doesn't make sense to enable ARBfp for the vertex program */
g_assert_not_reached ();
break;
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
/* don't need to to anything */
break;
}
/* ... and enable the new type */
switch (type)
{
case COGL_PIPELINE_PROGRAM_TYPE_ARBFP:
/* It doesn't make sense to enable ARBfp for the vertex program */
g_assert_not_reached ();
break;
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
/* don't need to to anything */
break;
}
}
if (type == COGL_PIPELINE_PROGRAM_TYPE_GLSL)
{
#ifdef COGL_PIPELINE_VERTEND_GLSL
set_glsl_program (gl_program);
#else
g_warning ("Unexpected use of GLSL vertend!");
#endif /* COGL_PIPELINE_VERTEND_GLSL */
}
#ifndef COGL_PIPELINE_VERTEND_ARBFP
else if (type == COGL_PIPELINE_PROGRAM_TYPE_ARBFP)
g_warning ("Unexpected use of ARBFP vertend!");
#endif /* COGL_PIPELINE_VERTEND_ARBFP */
ctx->current_vertex_program_type = type;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#if defined(HAVE_COGL_GLES2) || defined(HAVE_COGL_GL)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
static gboolean
blend_factor_uses_constant (GLenum blend_factor)
{
return (blend_factor == GL_CONSTANT_COLOR ||
blend_factor == GL_ONE_MINUS_CONSTANT_COLOR ||
blend_factor == GL_CONSTANT_ALPHA ||
blend_factor == GL_ONE_MINUS_CONSTANT_ALPHA);
}
#endif
static 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
flush_depth_state (CoglDepthState *depth_state)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
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
if (ctx->depth_test_function_cache != depth_state->test_function)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDepthFunc (depth_state->test_function));
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
ctx->depth_test_function_cache = depth_state->test_function;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
if (ctx->depth_writing_enabled_cache != depth_state->write_enabled)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDepthMask (depth_state->write_enabled ?
GL_TRUE : GL_FALSE));
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
ctx->depth_writing_enabled_cache = depth_state->write_enabled;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver != COGL_DRIVER_GLES1 &&
(ctx->depth_range_near_cache != depth_state->range_near ||
ctx->depth_range_far_cache != depth_state->range_far))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver == COGL_DRIVER_GLES2)
GE (ctx, glDepthRangef (depth_state->range_near,
depth_state->range_far));
else
GE (ctx, glDepthRange (depth_state->range_near,
depth_state->range_far));
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
ctx->depth_range_near_cache = depth_state->range_near;
ctx->depth_range_far_cache = depth_state->range_far;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
static void
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_flush_color_blend_alpha_depth_state (
CoglPipeline *pipeline,
unsigned long pipelines_difference,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
gboolean skip_gl_color)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
/* On GLES2 we'll flush the color later */
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver != COGL_DRIVER_GLES2 &&
!skip_gl_color)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
if ((pipelines_difference & COGL_PIPELINE_STATE_COLOR) ||
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* Assume if we were previously told to skip the color, then
* the current color needs updating... */
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
ctx->current_pipeline_skip_gl_color)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_COLOR);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glColor4ub (cogl_color_get_red_byte (&authority->color),
cogl_color_get_green_byte (&authority->color),
cogl_color_get_blue_byte (&authority->color),
cogl_color_get_alpha_byte (&authority->color)));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
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
if (pipelines_difference & COGL_PIPELINE_STATE_BLEND)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_BLEND);
CoglPipelineBlendState *blend_state =
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
&authority->big_state->blend_state;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* GLES 1 only has glBlendFunc */
if (ctx->driver == COGL_DRIVER_GLES1)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glBlendFunc (blend_state->blend_src_factor_rgb,
blend_state->blend_dst_factor_rgb));
}
#if defined(HAVE_COGL_GLES2) || defined(HAVE_COGL_GL)
else
{
if (blend_factor_uses_constant (blend_state->blend_src_factor_rgb) ||
blend_factor_uses_constant (blend_state
->blend_src_factor_alpha) ||
blend_factor_uses_constant (blend_state->blend_dst_factor_rgb) ||
blend_factor_uses_constant (blend_state->blend_dst_factor_alpha))
{
float red =
cogl_color_get_red_float (&blend_state->blend_constant);
float green =
cogl_color_get_green_float (&blend_state->blend_constant);
float blue =
cogl_color_get_blue_float (&blend_state->blend_constant);
float alpha =
cogl_color_get_alpha_float (&blend_state->blend_constant);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glBlendColor (red, green, blue, alpha));
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->glBlendEquationSeparate &&
blend_state->blend_equation_rgb !=
blend_state->blend_equation_alpha)
GE (ctx,
glBlendEquationSeparate (blend_state->blend_equation_rgb,
blend_state->blend_equation_alpha));
else
GE (ctx, glBlendEquation (blend_state->blend_equation_rgb));
if (ctx->glBlendFuncSeparate &&
(blend_state->blend_src_factor_rgb !=
blend_state->blend_src_factor_alpha ||
(blend_state->blend_src_factor_rgb !=
blend_state->blend_src_factor_alpha)))
GE (ctx, glBlendFuncSeparate (blend_state->blend_src_factor_rgb,
blend_state->blend_dst_factor_rgb,
blend_state->blend_src_factor_alpha,
blend_state->blend_dst_factor_alpha));
else
GE (ctx, glBlendFunc (blend_state->blend_src_factor_rgb,
blend_state->blend_dst_factor_rgb));
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#endif
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#if defined (HAVE_COGL_GL) || defined (HAVE_COGL_GLES)
cogl-pipeline: Flush the lighting params in common code not vertend The lighting parameters such as the diffuse and ambient colors were previously only flushed in the fixed vertend. This meant that if a vertex shader was used then they would not be set. The lighting parameters are uniforms which are just as useful in a fragment shader so it doesn't really make sense to set them in the vertend. They are now flushed in the common cogl-pipeline-opengl code but the code is #ifdef'd for GLES2 because they need to be part of the progend in that case.
2011-01-14 06:11:44 -05:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver != COGL_DRIVER_GLES2)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* Under GLES2 the alpha function is implemented as part of the
fragment shader */
if (pipelines_difference & (COGL_PIPELINE_STATE_ALPHA_FUNC |
COGL_PIPELINE_STATE_ALPHA_FUNC_REFERENCE))
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline,
COGL_PIPELINE_STATE_ALPHA_FUNC);
CoglPipelineAlphaFuncState *alpha_state =
&authority->big_state->alpha_state;
/* NB: Currently the Cogl defines are compatible with the GL ones: */
GE (ctx, glAlphaFunc (alpha_state->alpha_func,
alpha_state->alpha_func_reference));
}
cogl-pipeline: Flush the lighting params in common code not vertend The lighting parameters such as the diffuse and ambient colors were previously only flushed in the fixed vertend. This meant that if a vertex shader was used then they would not be set. The lighting parameters are uniforms which are just as useful in a fragment shader so it doesn't really make sense to set them in the vertend. They are now flushed in the common cogl-pipeline-opengl code but the code is #ifdef'd for GLES2 because they need to be part of the progend in that case.
2011-01-14 06:11:44 -05:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* Under GLES2 the lighting parameters are implemented as uniforms
in the progend */
if (pipelines_difference & COGL_PIPELINE_STATE_LIGHTING)
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline,
COGL_PIPELINE_STATE_LIGHTING);
CoglPipelineLightingState *lighting_state =
&authority->big_state->lighting_state;
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_AMBIENT,
lighting_state->ambient));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_DIFFUSE,
lighting_state->diffuse));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_SPECULAR,
lighting_state->specular));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_EMISSION,
lighting_state->emission));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_SHININESS,
&lighting_state->shininess));
}
cogl-pipeline: Flush the lighting params in common code not vertend The lighting parameters such as the diffuse and ambient colors were previously only flushed in the fixed vertend. This meant that if a vertex shader was used then they would not be set. The lighting parameters are uniforms which are just as useful in a fragment shader so it doesn't really make sense to set them in the vertend. They are now flushed in the common cogl-pipeline-opengl code but the code is #ifdef'd for GLES2 because they need to be part of the progend in that case.
2011-01-14 06:11:44 -05:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#endif
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
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
if (pipelines_difference & COGL_PIPELINE_STATE_DEPTH)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_DEPTH);
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
CoglDepthState *depth_state = &authority->big_state->depth_state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
if (depth_state->test_enabled)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
if (ctx->depth_test_enabled_cache != TRUE)
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glEnable (GL_DEPTH_TEST));
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
ctx->depth_test_enabled_cache = depth_state->test_enabled;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
flush_depth_state (depth_state);
}
else if (ctx->depth_test_enabled_cache != FALSE)
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDisable (GL_DEPTH_TEST));
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
ctx->depth_test_enabled_cache = depth_state->test_enabled;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
Adds ColorMask support to Cogl This adds CoglPipeline and CoglFramebuffer support for setting a color mask which is a bit mask defining which color channels should be written to the current framebuffer. The final color mask is the intersection of the framebuffer color mask and the pipeline color mask. The framebuffer mask affects all rendering to the framebuffer while the pipeline masks can be used to affect individual primitives. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-07-10 21:27:54 -04:00
if (pipelines_difference & COGL_PIPELINE_STATE_LOGIC_OPS)
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_LOGIC_OPS);
CoglPipelineLogicOpsState *logic_ops_state = &authority->big_state->logic_ops_state;
CoglColorMask color_mask = logic_ops_state->color_mask;
CoglFramebuffer *draw_framebuffer = cogl_get_draw_framebuffer ();
if (draw_framebuffer)
color_mask &= draw_framebuffer->color_mask;
GE (ctx, glColorMask (!!(color_mask & COGL_COLOR_MASK_RED),
!!(color_mask & COGL_COLOR_MASK_GREEN),
!!(color_mask & COGL_COLOR_MASK_BLUE),
!!(color_mask & COGL_COLOR_MASK_ALPHA)));
ctx->current_gl_color_mask = color_mask;
}
Make backface culling be part of the legacy state This adds an internal function to set the backface culling state on a pipeline. This includes properties to set the culling mode (front, back or both) and also to set which face is considered the front (COGL_WINDING_CLOCKWISE or COGL_WINDING_COUNTER_CLOCKWISE). The actual front face flushed to GL depends on whether we are rendering to an offscreen buffer or not. This means that when changing between on- and off- screen framebuffers it now checks whether the last flushed pipeline has backface culling enabled and forces a reflush of the cull face state if so. The backface culling is now set on a pipeline as part of the legacy state. This is important because some code in Cogl assumes it can flush a temporary pipeline to revert to a known state, but previously this wouldn't disable backface culling so things such as flushing the clip stack could get confused. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-15 06:25:39 -04:00
if (pipelines_difference & COGL_PIPELINE_STATE_CULL_FACE)
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_CULL_FACE);
CoglPipelineCullFaceState *cull_face_state
= &authority->big_state->cull_face_state;
if (cull_face_state->mode == COGL_PIPELINE_CULL_FACE_MODE_NONE)
GE( ctx, glDisable (GL_CULL_FACE) );
else
{
CoglFramebuffer *draw_framebuffer = cogl_get_draw_framebuffer ();
gboolean invert_winding;
GE( ctx, glEnable (GL_CULL_FACE) );
switch (cull_face_state->mode)
{
case COGL_PIPELINE_CULL_FACE_MODE_NONE:
g_assert_not_reached ();
case COGL_PIPELINE_CULL_FACE_MODE_FRONT:
GE( ctx, glCullFace (GL_FRONT) );
break;
case COGL_PIPELINE_CULL_FACE_MODE_BACK:
GE( ctx, glCullFace (GL_BACK) );
break;
case COGL_PIPELINE_CULL_FACE_MODE_BOTH:
GE( ctx, glCullFace (GL_FRONT_AND_BACK) );
break;
}
/* If we are painting to an offscreen framebuffer then we
need to invert the winding of the front face because
everything is painted upside down */
invert_winding = cogl_is_offscreen (draw_framebuffer);
switch (cull_face_state->front_winding)
{
case COGL_WINDING_CLOCKWISE:
GE( ctx, glFrontFace (invert_winding ? GL_CCW : GL_CW) );
break;
case COGL_WINDING_COUNTER_CLOCKWISE:
GE( ctx, glFrontFace (invert_winding ? GL_CW : GL_CCW) );
break;
}
}
}
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
if (pipeline->real_blend_enable != ctx->gl_blend_enable_cache)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
if (pipeline->real_blend_enable)
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glEnable (GL_BLEND));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
else
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDisable (GL_BLEND));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* XXX: we shouldn't update any other blend state if blending
* is disabled! */
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
ctx->gl_blend_enable_cache = pipeline->real_blend_enable;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
static int
get_max_activateable_texture_units (void)
{
_COGL_GET_CONTEXT (ctx, 0);
if (G_UNLIKELY (ctx->max_activateable_texture_units == -1))
{
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
GLint values[3];
int n_values = 0;
int i;
#ifdef HAVE_COGL_GL
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver == COGL_DRIVER_GL)
{
/* GL_MAX_TEXTURE_COORDS is provided for both GLSL and ARBfp. It
defines the number of texture coordinates that can be
uploaded (but doesn't necessarily relate to how many texture
images can be sampled) */
features: Support more than 32 features! Currently features are represented as bits in a 32bit mask so we obviously can't have more than 32 features with that approach. The new approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks without a size limit and we change the public api to accept individual feature enums instead of a mask. This way there is no limit on the number of features we can add to Cogl. Instead of using cogl_features_available() there is a new cogl_has_feature() function and for checking multiple features there is cogl_has_features() which takes a zero terminated vararg list of features. In addition to being able to check for individual features this also adds a way to query all the features currently available via cogl_foreach_feature() which will call a callback for each feature. Since the new functions take an explicit context pointer there is also no longer any ambiguity over when users can first start to query features. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-12 17:31:12 -04:00
if (cogl_has_feature (ctx, COGL_FEATURE_ID_GLSL) ||
cogl_has_feature (ctx, COGL_FEATURE_ID_ARBFP))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* Previously this code subtracted the value by one but there
was no explanation for why it did this and it doesn't seem
to make sense so it has been removed */
GE (ctx, glGetIntegerv (GL_MAX_TEXTURE_COORDS,
values + n_values++));
/* GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is defined for GLSL but
not ARBfp */
features: Support more than 32 features! Currently features are represented as bits in a 32bit mask so we obviously can't have more than 32 features with that approach. The new approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks without a size limit and we change the public api to accept individual feature enums instead of a mask. This way there is no limit on the number of features we can add to Cogl. Instead of using cogl_features_available() there is a new cogl_has_feature() function and for checking multiple features there is cogl_has_features() which takes a zero terminated vararg list of features. In addition to being able to check for individual features this also adds a way to query all the features currently available via cogl_foreach_feature() which will call a callback for each feature. Since the new functions take an explicit context pointer there is also no longer any ambiguity over when users can first start to query features. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-12 17:31:12 -04:00
if (cogl_has_feature (ctx, COGL_FEATURE_ID_GLSL))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glGetIntegerv (GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS,
values + n_values++));
}
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
#endif /* HAVE_COGL_GL */
#ifdef HAVE_COGL_GLES2
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver == COGL_DRIVER_GLES2)
{
GE (ctx, glGetIntegerv (GL_MAX_VERTEX_ATTRIBS, values + n_values));
/* Two of the vertex attribs need to be used for the position
and color */
values[n_values++] -= 2;
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glGetIntegerv (GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS,
values + n_values++));
}
#endif
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#if defined (HAVE_COGL_GL) || defined (HAVE_COGL_GLES) /* not GLES2 */
if (ctx->driver != COGL_DRIVER_GLES2)
{
/* GL_MAX_TEXTURE_UNITS defines the number of units that are
usable from the fixed function pipeline, therefore it isn't
available in GLES2. These are also tied to the number of
texture coordinates that can be uploaded so it should be less
than that available from the shader extensions */
GE (ctx, glGetIntegerv (GL_MAX_TEXTURE_UNITS,
values + n_values++));
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
}
#endif
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
g_assert (n_values <= G_N_ELEMENTS (values) &&
n_values > 0);
/* Use the maximum value */
ctx->max_activateable_texture_units = values[0];
for (i = 1; i < n_values; i++)
ctx->max_activateable_texture_units =
MAX (values[i], ctx->max_activateable_texture_units);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
return ctx->max_activateable_texture_units;
}
typedef struct
{
int i;
unsigned long *layer_differences;
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
} CoglPipelineFlushLayerState;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
static gboolean
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
flush_layers_common_gl_state_cb (CoglPipelineLayer *layer, void *user_data)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
CoglPipelineFlushLayerState *flush_state = user_data;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
int unit_index = flush_state->i;
CoglTextureUnit *unit = _cogl_get_texture_unit (unit_index);
unsigned long layers_difference =
flush_state->layer_differences[unit_index];
cogl-pipeline: Use layer overrides as CoglHandles instead of GLuint Since d5634e37 the sliced texture backend now works in terms of CoglTexture2Ds so there's no need to have special casing for overriding the texture of a pipeline layer with a GL handle. Instead we can just use cogl_pipeline_set_layer_texture with the CoglHandle. The special _cogl_pipeline_set_layer_gl_texture_slice function has now been removed and parts of the code for comparing materials have been simplified.
2010-11-11 11:18:25 -05:00
_COGL_GET_CONTEXT (ctx, FALSE);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* There may not be enough texture units so we can bail out if
* that's the case...
*/
if (G_UNLIKELY (unit_index >= get_max_activateable_texture_units ()))
{
static gboolean shown_warning = FALSE;
if (!shown_warning)
{
g_warning ("Your hardware does not have enough texture units"
"to handle this many texture layers");
shown_warning = TRUE;
}
return FALSE;
}
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
if (layers_difference & COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
unsigned long state = COGL_PIPELINE_LAYER_STATE_TEXTURE_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
CoglPipelineLayer *authority =
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
_cogl_pipeline_layer_get_authority (layer, state);
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *texture;
GLuint gl_texture;
GLenum gl_target;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
texture = (authority->texture == NULL ?
cogl-pipeline: Use layer overrides as CoglHandles instead of GLuint Since d5634e37 the sliced texture backend now works in terms of CoglTexture2Ds so there's no need to have special casing for overriding the texture of a pipeline layer with a GL handle. Instead we can just use cogl_pipeline_set_layer_texture with the CoglHandle. The special _cogl_pipeline_set_layer_gl_texture_slice function has now been removed and parts of the code for comparing materials have been simplified.
2010-11-11 11:18:25 -05:00
ctx->default_gl_texture_2d_tex :
authority->texture);
cogl_texture_get_gl_texture (texture,
&gl_texture,
&gl_target);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
_cogl_set_active_texture_unit (unit_index);
/* NB: There are several Cogl components and some code in
* Clutter that will temporarily bind arbitrary GL textures to
* query and modify texture object parameters. If you look at
* _cogl_bind_gl_texture_transient() you can see we make sure
* that such code always binds to texture unit 1 which means we
* can't rely on the unit->gl_texture state if unit->index == 1.
*
* Because texture unit 1 is a bit special we actually defer any
* necessary glBindTexture for it until the end of
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_flush_gl_state().
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
* NB: we get notified whenever glDeleteTextures is used (see
* _cogl_delete_gl_texture()) where we invalidate
* unit->gl_texture references to deleted textures so it's safe
* to compare unit->gl_texture with gl_texture. (Without the
* hook it would be possible to delete a GL texture and create a
* new one with the same name and comparing unit->gl_texture and
* gl_texture wouldn't detect that.)
*
* NB: for foreign textures we don't know how the deletion of
* the GL texture objects correspond to the deletion of the
* CoglTextures so if there was previously a foreign texture
* associated with the texture unit then we can't assume that we
* aren't seeing a recycled texture name so we have to bind.
*/
if (unit->gl_texture != gl_texture || unit->is_foreign)
{
Always bind a new texture to unit 1 when necessary The special handling for texture unit 1 caught the case where unit 1 was changed for transient purposes, but didn't properly handle the case where the actual non-transient texture was different between two materials with no transient binding in between. If the actual texture has changed when flushing, mark unit 1 as dirty and needing a rebind. http://bugzilla.clutter-project.org/show_bug.cgi?id=2261
2010-08-09 15:06:35 -04:00
if (unit_index == 1)
unit->dirty_gl_texture = TRUE;
else
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindTexture (gl_target, gl_texture));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unit->gl_texture = gl_texture;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->gl_target = gl_target;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
unit->is_foreign = _cogl_texture_is_foreign (texture);
/* The texture_storage_changed boolean indicates if the
* CoglTexture's underlying GL texture storage has changed since
* it was flushed to the texture unit. We've just flushed the
* latest state so we can reset this. */
unit->texture_storage_changed = FALSE;
}
Remove the fragment shader generation from the GLES2 wrapper The GLES2 wrapper no longer needs to generate any fragment shader state because the GLSL pipeline backend will always give the wrapper a custom fragment shader. This simplifies a lot of the state comparison done by the wrapper. The fog generation is also removed even though it's actually part of the vertex shader because only the fixed function pipeline backend actually calls the fog functions so it would be disabled when using any of the other backends anyway. We can fix this when the two shader backends also start generating vertex shaders.
2010-11-23 09:47:17 -05:00
/* Under GLES2 the fragment shader will use gl_PointCoord instead of
replacing the texture coordinates */
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#if defined (HAVE_COGL_GLES) || defined (HAVE_COGL_GL)
if (ctx->driver != COGL_DRIVER_GLES2 &&
(layers_difference & COGL_PIPELINE_LAYER_STATE_POINT_SPRITE_COORDS))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
CoglPipelineState change = COGL_PIPELINE_LAYER_STATE_POINT_SPRITE_COORDS;
CoglPipelineLayer *authority =
_cogl_pipeline_layer_get_authority (layer, change);
CoglPipelineLayerBigState *big_state = authority->big_state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
_cogl_set_active_texture_unit (unit_index);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glTexEnvi (GL_POINT_SPRITE, GL_COORD_REPLACE,
big_state->point_sprite_coords));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#endif
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
cogl_handle_ref (layer);
if (unit->layer != COGL_INVALID_HANDLE)
cogl_handle_unref (unit->layer);
unit->layer = layer;
unit->layer_changes_since_flush = 0;
flush_state->i++;
return TRUE;
}
static void
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_flush_common_gl_state (CoglPipeline *pipeline,
unsigned long pipelines_difference,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unsigned long *layer_differences,
gboolean skip_gl_color)
{
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
CoglPipelineFlushLayerState state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
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_flush_color_blend_alpha_depth_state (pipeline,
pipelines_difference,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
skip_gl_color);
state.i = 0;
state.layer_differences = layer_differences;
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_foreach_layer_internal (pipeline,
material: Adds experimental cogl_material_foreach_layer API This adds a way to iterate the layer indices of the given material since cogl_material_get_layers has been deprecated. The user provides a callback to be called once for each layer. Because modification of layers in the callback may potentially invalidate any number of the internal CoglMaterialLayer structures and invalidate the material's layer cache this should be more robust than cogl_material_get_layers() which used to return a const GList * pointing directly to internal state.
2010-07-05 16:33:26 -04:00
flush_layers_common_gl_state_cb,
&state);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
/* Re-assert the layer's wrap modes on the given CoglTexture.
*
* Note: we don't simply forward the wrap modes to layer->texture
* since the actual texture being used may have been overridden.
*/
static void
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_layer_forward_wrap_modes (CoglPipelineLayer *layer,
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *texture)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
CoglPipelineWrapModeInternal wrap_mode_s, wrap_mode_t, wrap_mode_p;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
GLenum gl_wrap_mode_s, gl_wrap_mode_t, gl_wrap_mode_p;
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
if (texture == NULL)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
return;
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_layer_get_wrap_modes (layer,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
&wrap_mode_s,
&wrap_mode_t,
&wrap_mode_p);
/* Update the wrap mode on the texture object. The texture backend
should cache the value so that it will be a no-op if the object
already has the same wrap mode set. The backend is best placed to
do this because it knows how many of the coordinates will
actually be used (ie, a 1D texture only cares about the 's'
coordinate but a 3D texture would use all three). GL uses the
wrap mode as part of the texture object state but we are
pretending it's part of the per-layer environment state. This
will break if the application tries to use different modes in
different layers using the same texture. */
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
if (wrap_mode_s == COGL_PIPELINE_WRAP_MODE_INTERNAL_AUTOMATIC)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
gl_wrap_mode_s = GL_CLAMP_TO_EDGE;
else
gl_wrap_mode_s = wrap_mode_s;
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
if (wrap_mode_t == COGL_PIPELINE_WRAP_MODE_INTERNAL_AUTOMATIC)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
gl_wrap_mode_t = GL_CLAMP_TO_EDGE;
else
gl_wrap_mode_t = wrap_mode_t;
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
if (wrap_mode_p == COGL_PIPELINE_WRAP_MODE_INTERNAL_AUTOMATIC)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
gl_wrap_mode_p = GL_CLAMP_TO_EDGE;
else
gl_wrap_mode_p = wrap_mode_p;
_cogl_texture_set_wrap_mode_parameters (texture,
gl_wrap_mode_s,
gl_wrap_mode_t,
gl_wrap_mode_p);
}
/* OpenGL associates the min/mag filters and repeat modes with the
* texture object not the texture unit so we always have to re-assert
* the filter and repeat modes whenever we use a texture since it may
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
* be referenced by multiple pipelines with different modes.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
* XXX: GL_ARB_sampler_objects fixes this in OpenGL so we should
* eventually look at using this extension when available.
*/
static void
foreach_texture_unit_update_filter_and_wrap_modes (void)
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
if (unit->layer)
{
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *texture = _cogl_pipeline_layer_get_texture (unit->layer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
if (texture != NULL)
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
{
CoglPipelineFilter min;
CoglPipelineFilter mag;
_cogl_pipeline_layer_get_filters (unit->layer, &min, &mag);
_cogl_texture_set_filters (texture, min, mag);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
_cogl_pipeline_layer_forward_wrap_modes (unit->layer, texture);
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
}
typedef struct
{
int i;
unsigned long *layer_differences;
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
} CoglPipelineCompareLayersState;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
static gboolean
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
compare_layer_differences_cb (CoglPipelineLayer *layer, void *user_data)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
CoglPipelineCompareLayersState *state = user_data;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
CoglTextureUnit *unit = _cogl_get_texture_unit (state->i);
if (unit->layer == layer)
state->layer_differences[state->i] = unit->layer_changes_since_flush;
else if (unit->layer)
{
state->layer_differences[state->i] = unit->layer_changes_since_flush;
state->layer_differences[state->i] |=
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_layer_compare_differences (layer, unit->layer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
else
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
state->layer_differences[state->i] = COGL_PIPELINE_LAYER_STATE_ALL_SPARSE;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* XXX: There is always a possibility that a CoglTexture's
* underlying GL texture storage has been changed since it was last
* bound to a texture unit which is why we have a callback into
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_texture_storage_change_notify whenever a textures
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* underlying GL texture storage changes which will set the
* unit->texture_intern_changed flag. If we see that's been set here
* then we force an update of the texture state...
*/
if (unit->texture_storage_changed)
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
state->layer_differences[state->i] |=
COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
state->i++;
return TRUE;
}
typedef struct
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
const CoglPipelineFragend *fragend;
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
CoglPipeline *pipeline;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unsigned long *layer_differences;
gboolean error_adding_layer;
gboolean added_layer;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
} CoglPipelineFragendAddLayerState;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
static gboolean
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
fragend_add_layer_cb (CoglPipelineLayer *layer,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
void *user_data)
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendAddLayerState *state = user_data;
const CoglPipelineFragend *fragend = state->fragend;
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
CoglPipeline *pipeline = state->pipeline;
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
_COGL_GET_CONTEXT (ctx, FALSE);
/* Either generate per layer code snippets or setup the
* fixed function glTexEnv for each layer... */
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
if (G_LIKELY (fragend->add_layer (pipeline,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
layer,
state->layer_differences[unit_index])))
state->added_layer = TRUE;
else
{
state->error_adding_layer = TRUE;
return FALSE;
}
return TRUE;
}
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
typedef struct
{
const CoglPipelineVertend *vertend;
CoglPipeline *pipeline;
unsigned long *layer_differences;
gboolean error_adding_layer;
gboolean added_layer;
} CoglPipelineVertendAddLayerState;
static gboolean
vertend_add_layer_cb (CoglPipelineLayer *layer,
void *user_data)
{
CoglPipelineVertendAddLayerState *state = user_data;
const CoglPipelineVertend *vertend = state->vertend;
CoglPipeline *pipeline = state->pipeline;
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
_COGL_GET_CONTEXT (ctx, FALSE);
/* Either enerate per layer code snippets or setup the
* fixed function matrix uniforms for each layer... */
if (G_LIKELY (vertend->add_layer (pipeline,
layer,
state->layer_differences[unit_index])))
state->added_layer = TRUE;
else
{
state->error_adding_layer = TRUE;
return FALSE;
}
return TRUE;
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/*
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_flush_gl_state:
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
* Details of override options:
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
* ->fallback_mask: is a bitmask of the pipeline layers that need to be
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* replaced with the default, fallback textures. The fallback textures are
* fully transparent textures so they hopefully wont contribute to the
* texture combining.
*
* The intention of fallbacks is to try and preserve
* the number of layers the user is expecting so that texture coordinates
* they gave will mostly still correspond to the textures they intended, and
* have a fighting chance of looking close to their originally intended
* result.
*
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
* ->disable_mask: is a bitmask of the pipeline layers that will simply have
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* texturing disabled. It's only really intended for disabling all layers
* > X; i.e. we'd expect to see a contiguous run of 0 starting from the LSB
* and at some point the remaining bits flip to 1. It might work to disable
* arbitrary layers; though I'm not sure a.t.m how OpenGL would take to
* that.
*
* The intention of the disable_mask is for emitting geometry when the user
* hasn't supplied enough texture coordinates for all the layers and it's
* not possible to auto generate default texture coordinates for those
* layers.
*
* ->layer0_override_texture: forcibly tells us to bind this GL texture name for
* layer 0 instead of plucking the gl_texture from the CoglTexture of layer
* 0.
*
* The intention of this is for any primitives that supports sliced textures.
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
* The code will can iterate each of the slices and re-flush the pipeline
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* forcing the GL texture of each slice in turn.
*
* ->wrap_mode_overrides: overrides the wrap modes set on each
* layer. This is used to implement the automatic wrap mode.
*
* XXX: It might also help if we could specify a texture matrix for code
* dealing with slicing that would be multiplied with the users own matrix.
*
* Normaly texture coords in the range [0, 1] refer to the extents of the
* texture, but when your GL texture represents a slice of the real texture
* (from the users POV) then a texture matrix would be a neat way of
* transforming the mapping for each slice.
*
* Currently for textured rectangles we manually calculate the texture
* coords for each slice based on the users given coords, but this solution
* isn't ideal, and can't be used with CoglVertexBuffers.
*/
void
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_flush_gl_state (CoglPipeline *pipeline,
Revert "cogl: Remove the generated array size for cogl_tex_coord_in" This reverts commit 4cfe90bde275dbb952645397aa2ba2d6f6e2f3ba. GLSL 1.00 on GLES doesn't support unsized arrays so the whole idea can't work. Conflicts: clutter/cogl/cogl/cogl-pipeline-glsl.c
2010-12-02 16:08:30 -05:00
gboolean skip_gl_color,
int n_tex_coord_attribs)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
unsigned long pipelines_difference;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
int n_layers;
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
unsigned long *layer_differences;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
int i;
CoglTextureUnit *unit1;
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_STATIC_TIMER (pipeline_flush_timer,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
"Mainloop", /* parent */
"Material Flush",
"The time spent flushing material state",
0 /* no application private data */);
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
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_TIMER_START (_cogl_uprof_context, pipeline_flush_timer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
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
if (ctx->current_pipeline == pipeline)
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
{
/* Bail out asap if we've been asked to re-flush the already current
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
* pipeline and we can see the pipeline hasn't changed */
pipeline: don't skip flush if skip_gl_color flag differs We try and bail out of flushing pipeline state asap if we can see the pipeline has already been flushed and hasn't changed but we weren't checking to see if the skip_gl_color flag is the same as when it was last flush too and so we'd sometimes bail out without updating the glColor correctly.
2011-01-11 09:10:11 -05:00
if (ctx->current_pipeline_age == pipeline->age &&
ctx->current_pipeline_skip_gl_color == skip_gl_color)
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
goto done;
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
pipelines_difference = ctx->current_pipeline_changes_since_flush;
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
}
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
else if (ctx->current_pipeline)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
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
pipelines_difference = ctx->current_pipeline_changes_since_flush;
pipelines_difference |=
_cogl_pipeline_compare_differences (ctx->current_pipeline,
pipeline);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
else
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
pipelines_difference = COGL_PIPELINE_STATE_ALL_SPARSE;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* Get a layer_differences mask for each layer to be flushed */
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
n_layers = cogl_pipeline_get_n_layers (pipeline);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
if (n_layers)
{
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
CoglPipelineCompareLayersState state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
layer_differences = g_alloca (sizeof (unsigned long *) * n_layers);
memset (layer_differences, 0, sizeof (layer_differences));
state.i = 0;
state.layer_differences = layer_differences;
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_foreach_layer_internal (pipeline,
material: Adds experimental cogl_material_foreach_layer API This adds a way to iterate the layer indices of the given material since cogl_material_get_layers has been deprecated. The user provides a callback to be called once for each layer. Because modification of layers in the callback may potentially invalidate any number of the internal CoglMaterialLayer structures and invalidate the material's layer cache this should be more robust than cogl_material_get_layers() which used to return a const GList * pointing directly to internal state.
2010-07-05 16:33:26 -04:00
compare_layer_differences_cb,
&state);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
else
layer_differences = NULL;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* First flush everything that's the same regardless of which
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
* pipeline backend is being used...
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
* 1) top level state:
* glColor (or skip if a vertex attribute is being used for color)
* blend state
* alpha test state (except for GLES 2.0)
*
* 2) then foreach layer:
* determine gl_target/gl_texture
* bind texture
*
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
* Note: After _cogl_pipeline_flush_common_gl_state you can expect
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* all state of the layers corresponding texture unit to be
* updated.
*/
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_flush_common_gl_state (pipeline,
pipelines_difference,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
layer_differences,
skip_gl_color);
/* Now flush the fragment processing state according to the current
* fragment processing backend.
*
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
* Note: Some of the backends may not support the current pipeline
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* configuration and in that case it will report an error and we
* will fallback to a different backend.
*
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
* NB: if pipeline->backend != COGL_PIPELINE_FRAGEND_UNDEFINED then
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
* we have previously managed to successfully flush this pipeline
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* with the given backend so we will simply use that to avoid
* fallback code paths.
*/
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
if (pipeline->fragend == COGL_PIPELINE_FRAGEND_UNDEFINED)
_cogl_pipeline_set_fragend (pipeline, COGL_PIPELINE_FRAGEND_DEFAULT);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
for (i = pipeline->fragend;
i < G_N_ELEMENTS (_cogl_pipeline_fragends);
i++, _cogl_pipeline_set_fragend (pipeline, i))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
const CoglPipelineFragend *fragend = _cogl_pipeline_fragends[i];
CoglPipelineFragendAddLayerState state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
/* E.g. For fragends generating code they can setup their
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* scratch buffers here... */
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
if (G_UNLIKELY (!fragend->start (pipeline,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
n_layers,
Revert "cogl: Remove the generated array size for cogl_tex_coord_in" This reverts commit 4cfe90bde275dbb952645397aa2ba2d6f6e2f3ba. GLSL 1.00 on GLES doesn't support unsized arrays so the whole idea can't work. Conflicts: clutter/cogl/cogl/cogl-pipeline-glsl.c
2010-12-02 16:08:30 -05:00
pipelines_difference,
n_tex_coord_attribs)))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
continue;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
state.fragend = fragend;
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
state.pipeline = pipeline;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
state.layer_differences = layer_differences;
state.error_adding_layer = FALSE;
state.added_layer = 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 13:54:57 -04:00
_cogl_pipeline_foreach_layer_internal (pipeline,
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
fragend_add_layer_cb,
material: Adds experimental cogl_material_foreach_layer API This adds a way to iterate the layer indices of the given material since cogl_material_get_layers has been deprecated. The user provides a callback to be called once for each layer. Because modification of layers in the callback may potentially invalidate any number of the internal CoglMaterialLayer structures and invalidate the material's layer cache this should be more robust than cogl_material_get_layers() which used to return a const GList * pointing directly to internal state.
2010-07-05 16:33:26 -04:00
&state);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
if (G_UNLIKELY (state.error_adding_layer))
continue;
if (!state.added_layer &&
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
fragend->passthrough &&
G_UNLIKELY (!fragend->passthrough (pipeline)))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
continue;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
/* For fragends generating code they may compile and link their
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* programs here, update any uniforms and tell OpenGL to use
* that program.
*/
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
if (G_UNLIKELY (!fragend->end (pipeline, pipelines_difference)))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
continue;
break;
}
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
if (G_UNLIKELY (i >= G_N_ELEMENTS (_cogl_pipeline_fragends)))
g_warning ("No usable pipeline fragment backend was found!");
Add a warning message when no usable Cogl pipeline backend is found If none of the pipeline backends can handle the state then it now displays a warning so the developer has a chance to work out what's going on.
2010-11-24 12:37:55 -05:00
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
/* Now flush the vertex processing state according to the current
* vertex processing backend.
*/
if (pipeline->vertend == COGL_PIPELINE_VERTEND_UNDEFINED)
_cogl_pipeline_set_vertend (pipeline, COGL_PIPELINE_VERTEND_DEFAULT);
for (i = pipeline->vertend;
i < G_N_ELEMENTS (_cogl_pipeline_vertends);
i++, _cogl_pipeline_set_vertend (pipeline, i))
{
const CoglPipelineVertend *vertend = _cogl_pipeline_vertends[i];
CoglPipelineVertendAddLayerState state;
/* E.g. For vertends generating code they can setup their
* scratch buffers here... */
if (G_UNLIKELY (!vertend->start (pipeline,
n_layers,
pipelines_difference)))
continue;
state.vertend = vertend;
state.pipeline = pipeline;
state.layer_differences = layer_differences;
state.error_adding_layer = FALSE;
state.added_layer = FALSE;
_cogl_pipeline_foreach_layer_internal (pipeline,
vertend_add_layer_cb,
&state);
if (G_UNLIKELY (state.error_adding_layer))
continue;
/* For vertends generating code they may compile and link their
* programs here, update any uniforms and tell OpenGL to use
* that program.
*/
if (G_UNLIKELY (!vertend->end (pipeline, pipelines_difference)))
continue;
break;
}
if (G_UNLIKELY (i >= G_N_ELEMENTS (_cogl_pipeline_vertends)))
g_warning ("No usable pipeline vertex backend was found!");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
for (i = 0; i < COGL_PIPELINE_N_PROGENDS; i++)
if (_cogl_pipeline_progends[i]->end)
_cogl_pipeline_progends[i]->end (pipeline, pipelines_difference,
n_tex_coord_attribs);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* FIXME: This reference is actually resulting in lots of
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
* copy-on-write reparenting because one-shot pipelines end up
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* living for longer than necessary and so any later modification of
* the parent will cause a copy-on-write.
*
* XXX: The issue should largely go away when we switch to using
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
* weak pipelines for overrides.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*/
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_object_ref (pipeline);
if (ctx->current_pipeline != NULL)
cogl_object_unref (ctx->current_pipeline);
ctx->current_pipeline = pipeline;
ctx->current_pipeline_changes_since_flush = 0;
ctx->current_pipeline_skip_gl_color = skip_gl_color;
ctx->current_pipeline_age = pipeline->age;
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
done:
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
/* We can't assume the color will be retained between flushes on
GLES2 because the generic attribute values are not stored as part
of the program object so they could be overridden by any
attribute changes in another program */
#ifdef HAVE_COGL_GLES2
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver == COGL_DRIVER_GLES2 && !skip_gl_color)
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
{
int attribute;
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_COLOR);
attribute = _cogl_pipeline_progend_glsl_get_color_attribute (pipeline);
if (attribute != -1)
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx,
glVertexAttrib4f (attribute,
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
cogl_color_get_red_float (&authority->color),
cogl_color_get_green_float (&authority->color),
cogl_color_get_blue_float (&authority->color),
cogl_color_get_alpha_float (&authority->color)));
}
#endif
cogl: upload matrices with uniforms on GLES2 Once the GLES2 wrapper is removed we won't be able to upload the matrices with the fixed function API any more. The fixed function API gives a global state for setting the matrix but if a custom shader uniform is used for the matrices then the state is per program. _cogl_matrix_stack_flush_to_gl is called in a few places and it is assumed the current pipeline doesn't need to be flushed before it is called. To allow these semantics to continue to work, on GLES2 the matrix flush now just stores a reference to the matrix stack in the CoglContext. A pre_paint virtual is added to the progend which is called whenever a pipeline is flushed, even if the same pipeline was flushed already. This gives the GLSL progend a chance to upload the matrices to the uniforms. The combined modelview/projection matrix is only calculated if it is used. The generated programs end up never using the modelview or projection matrix so it usually only has to upload the combined matrix. When a matrix stack is flushed a reference is taked to it by the pipeline progend and the age is stored so that if the same state is used with the same program again then we don't need to reupload the uniform.
2010-12-06 07:31:51 -05:00
/* Give any progends a chance to update any uniforms that might not
depend on the material state. This is used on GLES2 to update the
matrices */
for (i = 0; i < COGL_PIPELINE_N_PROGENDS; i++)
if (_cogl_pipeline_progends[i]->pre_paint)
_cogl_pipeline_progends[i]->pre_paint (pipeline);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* Handle the fact that OpenGL associates texture filter and wrap
* modes with the texture objects not the texture units... */
foreach_texture_unit_update_filter_and_wrap_modes ();
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
/* If this pipeline has more than one layer then we always need
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* to make sure we rebind the texture for unit 1.
*
* NB: various components of Cogl may temporarily bind arbitrary
* textures to texture unit 1 so they can query and modify texture
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
* object parameters. cogl-pipeline.c (See
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* _cogl_bind_gl_texture_transient)
*/
unit1 = _cogl_get_texture_unit (1);
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
if (cogl_pipeline_get_n_layers (pipeline) > 1 && unit1->dirty_gl_texture)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
_cogl_set_active_texture_unit (1);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindTexture (unit1->gl_target, unit1->gl_texture));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unit1->dirty_gl_texture = 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 13:54:57 -04:00
COGL_TIMER_STOP (_cogl_uprof_context, pipeline_flush_timer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
Reference in New Issue Copy Permalink