brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
232d8dc67c
mutter/cogl/cogl-matrix-stack.h

621 lines
22 KiB
C
Raw Normal View History

Virtualize GL matrix operations and use a client-side matrix when GL is indirect This is useful because sometimes we need to get the current matrix, which is too expensive when indirect rendering. In addition, this virtualization makes it easier to clean up the API in the future.
2009-02-24 13:51:25 -05:00
/*
[cogl] Updates all file headers and removes lots of trailing white space Adds missing notices, and ensures all the notices are consistent. The Cogl blurb also now reads: * Cogl * * An object oriented GL/GLES Abstraction/Utility Layer
2009-04-27 10:48:12 -04:00
* Cogl
Virtualize GL matrix operations and use a client-side matrix when GL is indirect This is useful because sometimes we need to get the current matrix, which is too expensive when indirect rendering. In addition, this virtualization makes it easier to clean up the API in the future.
2009-02-24 13:51:25 -05:00
*
[cogl] Updates all file headers and removes lots of trailing white space Adds missing notices, and ensures all the notices are consistent. The Cogl blurb also now reads: * Cogl * * An object oriented GL/GLES Abstraction/Utility Layer
2009-04-27 10:48:12 -04:00
* An object oriented GL/GLES Abstraction/Utility Layer
Virtualize GL matrix operations and use a client-side matrix when GL is indirect This is useful because sometimes we need to get the current matrix, which is too expensive when indirect rendering. In addition, this virtualization makes it easier to clean up the API in the future.
2009-02-24 13:51:25 -05:00
*
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
* Copyright (C) 2009,2010,2012 Intel Corporation.
Virtualize GL matrix operations and use a client-side matrix when GL is indirect This is useful because sometimes we need to get the current matrix, which is too expensive when indirect rendering. In addition, this virtualization makes it easier to clean up the API in the future.
2009-02-24 13:51:25 -05:00
*
* 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
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
Remove mentions of the FSF address Since using addresses that might change is something that finally the FSF acknowledge as a plausible scenario (after changing address twice), the license blurb in the source files should use the URI for getting the license in case the library did not come with it. Not that URIs cannot possibly change, but at least it's easier to set up a redirection at the same place. As a side note: this commit closes the oldes bug in Clutter's bug report tool. http://bugzilla.openedhand.com/show_bug.cgi?id=521
2010-03-01 07:56:10 -05:00
*
*
[cogl] Updates all file headers and removes lots of trailing white space Adds missing notices, and ensures all the notices are consistent. The Cogl blurb also now reads: * Cogl * * An object oriented GL/GLES Abstraction/Utility Layer
2009-04-27 10:48:12 -04:00
*
* Authors:
* Havoc Pennington <hp@pobox.com> for litl
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
* Robert Bragg <robert@linux.intel.com>
Virtualize GL matrix operations and use a client-side matrix when GL is indirect This is useful because sometimes we need to get the current matrix, which is too expensive when indirect rendering. In addition, this virtualization makes it easier to clean up the API in the future.
2009-02-24 13:51:25 -05:00
*/
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
#ifndef _COGL_MATRIX_STACK_H_
#define _COGL_MATRIX_STACK_H_
Virtualize GL matrix operations and use a client-side matrix when GL is indirect This is useful because sometimes we need to get the current matrix, which is too expensive when indirect rendering. In addition, this virtualization makes it easier to clean up the API in the future.
2009-02-24 13:51:25 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
#if !defined(__COGL_H_INSIDE__) && !defined(COGL_COMPILATION)
#error "Only <cogl/cogl.h> can be included directly."
matrix-stack: only maintain composite_gets in debug builds At times there can be huge numbers of CoglMatrixEntry structures allocated if they are being used to track the transform of many drawing commands or objects in a scenegraph. Therefore the size of a CoglMatrixEntry should be kept as small as possible both to help reduce the memory usage of applications but also to improve cache usage since matrix stack manipulations are performance critical at times. This reduces the size of CoglMatrixEntry structures for non-debug builds by removing the composite_gets counter used to sanity check how often the transform for an entry is resolved. (cherry picked from commit c400b86681a328b1e12b7e120e9c3f4f12c356e0)
2012-11-20 12:47:21 -05:00
#endif
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
#include "cogl-matrix.h"
#include "cogl-context.h"
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* SECTION:cogl-matrix-stack
* @short_description: Functions for efficiently tracking many
* related transformations
*
* Matrices can be used (for example) to describe the model-view
* transforms of objects, texture transforms, and projective
* transforms.
*
* The #CoglMatrix api provides a good way to manipulate individual
* matrices representing a single transformation but if you need to
* track many-many such transformations for many objects that are
* organized in a scenegraph for example then using a separate
* #CoglMatrix for each object may not be the most efficient way.
*
* A #CoglMatrixStack enables applications to track lots of
* transformations that are related to each other in some kind of
* hierarchy. In a scenegraph for example if you want to know how to
* transform a particular node then you usually have to walk up
* through the ancestors and accumulate their transforms before
* finally applying the transform of the node itself. In this model
* things are grouped together spatially according to their ancestry
* and all siblings with the same parent share the same initial
* transformation. The #CoglMatrixStack API is suited to tracking lots
* of transformations that fit this kind of model.
*
* Compared to using the #CoglMatrix api directly to track many
* related transforms, these can be some advantages to using a
* #CoglMatrixStack:
doc: Don't use the HTML <ul> but the DocBook equivalent Of course, this confused gtk-doc. (cherry picked from commit be512104784a9200a2e98a75d16a56e3897a8845)
2012-12-31 09:59:55 -05:00
* <itemizedlist>
* <listitem>Faster equality comparisons of transformations</listitem>
* <listitem>Efficient comparisons of the differences between arbitrary
* transformations</listitem>
* <listitem>Avoid redundant arithmetic related to common transforms
* </listitem>
* <listitem>Can be more space efficient (not always though)</listitem>
* </itemizedlist>
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
*
* For reference (to give an idea of when a #CoglMatrixStack can
* provide a space saving) a #CoglMatrix can be expected to take 72
* bytes whereas a single #CoglMatrixEntry in a #CoglMatrixStack is
* currently around 32 bytes on a 32bit CPU or 36 bytes on a 64bit
* CPU. An entry is needed for each individual operation applied to
* the stack (such as rotate, scale, translate) so if most of your
* leaf node transformations only need one or two simple operations
* relative to their parent then a matrix stack will likely take less
* space than having a #CoglMatrix for each node.
*
* Even without any space saving though the ability to perform fast
* comparisons and avoid redundant arithmetic (especially sine and
* cosine calculations for rotations) can make using a matrix stack
* worthwhile.
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* CoglMatrixStack:
*
* Tracks your current position within a hierarchy and lets you build
* up a graph of transformations as you traverse through a hierarchy
* such as a scenegraph.
*
* A #CoglMatrixStack always maintains a reference to a single
* transformation at any point in time, representing the
* transformation at the current position in the hierarchy. You can
* get a reference to the current transformation by calling
* cogl_matrix_stack_get_entry().
*
* When a #CoglMatrixStack is first created with
* cogl_matrix_stack_new() then it is conceptually positioned at the
* root of your hierarchy and the current transformation simply
* represents an identity transformation.
*
* As you traverse your object hierarchy (your scenegraph) then you
* should call cogl_matrix_stack_push() whenever you move down one
* level and call cogl_matrix_stack_pop() whenever you move back up
* one level towards the root.
*
* At any time you can apply a set of operations, such as "rotate",
* "scale", "translate" on top of the current transformation of a
* #CoglMatrixStack using functions such as
* cogl_matrix_stack_rotate(), cogl_matrix_stack_scale() and
* cogl_matrix_stack_translate(). These operations will derive a new
* current transformation and will never affect a transformation
* that you have referenced using cogl_matrix_stack_get_entry().
*
* Internally applying operations to a #CoglMatrixStack builds up a
* graph of #CoglMatrixEntry structures which each represent a single
* immutable transform.
*/
typedef struct _CoglMatrixStack CoglMatrixStack;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* CoglMatrixEntry:
*
* Represents a single immutable transformation that was retrieved
* from a #CoglMatrixStack using cogl_matrix_stack_get_entry().
*
* Internally a #CoglMatrixEntry represents a single matrix
* operation (such as "rotate", "scale", "translate") which is applied
* to the transform of a single parent entry.
*
* Using the #CoglMatrixStack api effectively builds up a graph of
* these immutable #CoglMatrixEntry structures whereby operations
* that can be shared between multiple transformations will result
* in shared #CoglMatrixEntry nodes in the graph.
*
* When a #CoglMatrixStack is first created it references one
* #CoglMatrixEntry that represents a single "load identity"
* operation. This serves as the root entry and all operations
* that are then applied to the stack will extend the graph
* starting from this root "load identity" entry.
*
* Given the typical usage model for a #CoglMatrixStack and the way
* the entries are built up while traversing a scenegraph then in most
* cases where an application is interested in comparing two
* transformations for equality then it is enough to simply compare
* two #CoglMatrixEntry pointers directly. Technically this can lead
* to false negatives that could be identified with a deeper
* comparison but often these false negatives are unlikely and
* don't matter anyway so this enables extremely cheap comparisons.
*
* <note>#CoglMatrixEntry<!-- -->s are reference counted using
* cogl_matrix_entry_ref() and cogl_matrix_entry_unref() not with
* cogl_object_ref() and cogl_object_unref().</note>
*/
typedef struct _CoglMatrixEntry CoglMatrixEntry;
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
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_new:
doc: Unhide cogl-matrix-stack.h The documentation welcomes a new 2.0 API. (cherry picked from commit 8d78957c8d29b89c7bf352131d84c9755083eed9)
2012-12-30 14:49:56 -05:00
* @ctx: A #CoglContext
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
*
* Allocates a new #CoglMatrixStack that can be used to build up
* transformations relating to objects in a scenegraph like hierarchy.
* (See the description of #CoglMatrixStack and #CoglMatrixEntry for
* more details of what a matrix stack is best suited for)
*
* When a #CoglMatrixStack is first allocated it is conceptually
* positioned at the root of your scenegraph hierarchy. As you
* traverse your scenegraph then you should call
* cogl_matrix_stack_push() whenever you move down a level and
* cogl_matrix_stack_pop() whenever you move back up a level towards
* the root.
*
* Once you have allocated a #CoglMatrixStack you can get a reference
* to the current transformation for the current position in the
* hierarchy by calling cogl_matrix_stack_get_entry().
*
* Once you have allocated a #CoglMatrixStack you can apply operations
* such as rotate, scale and translate to modify the current transform
* for the current position in the hierarchy by calling
* cogl_matrix_stack_rotate(), cogl_matrix_stack_scale() and
* cogl_matrix_stack_translate().
*
* Return value: A newly allocated #CoglMatrixStack
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
CoglMatrixStack *
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_new (CoglContext *ctx);
[matrix] Adds cogl_matrix_get_inverse API This new API takes advantage of the recently imported Mesa code to support inverse matrix calculation. The matrix code keeps track (via internal flags) of the transformations a matrix represents so that it can select an optimized inversion function. Note: although other aspects of the Cogl matrix API have followed a similar style to Cairo's matrix API we haven't added a cogl_matrix_invert API because the inverse of a CoglMatrix is actually cached as part of the CoglMatrix structure meaning a destructive API like cogl_matrix_invert doesn't let users take advantage of this caching design.
2009-10-26 13:51:34 -04:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_push:
* @stack: A #CoglMatrixStack
*
* Saves the current transform and starts a new transform that derives
* from the current transform.
*
* This is usually called while traversing a scenegraph whenever you
* traverse one level deeper. cogl_matrix_stack_pop() can then be
* called when going back up one layer to restore the previous
* transform of an ancestor.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_push (CoglMatrixStack *stack);
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_pop:
* @stack: A #CoglMatrixStack
*
* Restores the previous transform that was last saved by calling
* cogl_matrix_stack_push().
*
* This is usually called while traversing a scenegraph whenever you
* return up one level in the graph towards the root node.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_pop (CoglMatrixStack *stack);
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_load_identity:
* @stack: A #CoglMatrixStack
*
* Resets the current matrix to the identity matrix.
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_load_identity (CoglMatrixStack *stack);
/**
* cogl_matrix_stack_scale:
* @stack: A #CoglMatrixStack
* @x: Amount to scale along the x-axis
* @y: Amount to scale along the y-axis
* @z: Amount to scale along the z-axis
*
* Multiplies the current matrix by one that scales the x, y and z
* axes by the given values.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_scale (CoglMatrixStack *stack,
float x,
float y,
float z);
/**
* cogl_matrix_stack_translate:
* @stack: A #CoglMatrixStack
* @x: Distance to translate along the x-axis
* @y: Distance to translate along the y-axis
* @z: Distance to translate along the z-axis
*
* Multiplies the current matrix by one that translates along all
* three axes according to the given values.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_translate (CoglMatrixStack *stack,
float x,
float y,
float z);
/**
* cogl_matrix_stack_rotate:
* @stack: A #CoglMatrixStack
* @angle: Angle in degrees to rotate.
* @x: X-component of vertex to rotate around.
* @y: Y-component of vertex to rotate around.
* @z: Z-component of vertex to rotate around.
*
* Multiplies the current matrix by one that rotates the around the
* axis-vector specified by @x, @y and @z. The rotation follows the
* right-hand thumb rule so for example rotating by 10 degrees about
* the axis-vector (0, 0, 1) causes a small counter-clockwise
* rotation.
*/
void
cogl_matrix_stack_rotate (CoglMatrixStack *stack,
float angle,
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
float x,
float y,
float z);
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_rotate_quaternion:
* @stack: A #CoglMatrixStack
* @quaternion: A #CoglQuaternion
*
* Multiplies the current matrix by one that rotates according to the
* rotation described by @quaternion.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_rotate_quaternion (CoglMatrixStack *stack,
const CoglQuaternion *quaternion);
/**
* cogl_matrix_stack_rotate_euler:
* @stack: A #CoglMatrixStack
* @euler: A #CoglEuler
*
* Multiplies the current matrix by one that rotates according to the
* rotation described by @euler.
*/
Add functions to directly transform from a euler or a quaternion This adds the following new functions to apply a rotation described by a euler or a quaternion to either a CoglMatrix or directly to the modelview stack of a framebuffer: cogl_matrix_rotate_quaternion cogl_matrix_rotate_euler cogl_framebuffer_rotate_quaternion cogl_framebuffer_rotate_euler The direct framebuffer functions have corresponding functions in the CoglMatrixStack to store an entry describing the rotation. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 5064315678b496395e1d01f266f322d73e55e324)
2012-05-17 17:22:01 -04:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_rotate_euler (CoglMatrixStack *stack,
const CoglEuler *euler);
/**
* cogl_matrix_stack_multiply:
* @stack: A #CoglMatrixStack
* @matrix: the matrix to multiply with the current model-view
*
* Multiplies the current matrix by the given matrix.
*/
Add functions to directly transform from a euler or a quaternion This adds the following new functions to apply a rotation described by a euler or a quaternion to either a CoglMatrix or directly to the modelview stack of a framebuffer: cogl_matrix_rotate_quaternion cogl_matrix_rotate_euler cogl_framebuffer_rotate_quaternion cogl_framebuffer_rotate_euler The direct framebuffer functions have corresponding functions in the CoglMatrixStack to store an entry describing the rotation. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 5064315678b496395e1d01f266f322d73e55e324)
2012-05-17 17:22:01 -04:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_multiply (CoglMatrixStack *stack,
const CoglMatrix *matrix);
/**
* cogl_matrix_stack_frustum:
* @stack: A #CoglMatrixStack
* @left: X position of the left clipping plane where it
* intersects the near clipping plane
* @right: X position of the right clipping plane where it
* intersects the near clipping plane
* @bottom: Y position of the bottom clipping plane where it
* intersects the near clipping plane
* @top: Y position of the top clipping plane where it intersects
* the near clipping plane
* @z_near: The distance to the near clipping plane (Must be positive)
* @z_far: The distance to the far clipping plane (Must be positive)
*
* Replaces the current matrix with a perspective matrix for a given
* viewing frustum defined by 4 side clip planes that all cross
* through the origin and 2 near and far clip planes.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_frustum (CoglMatrixStack *stack,
float left,
float right,
float bottom,
float top,
float z_near,
float z_far);
/**
* cogl_matrix_stack_perspective:
* @stack: A #CoglMatrixStack
* @fov_y: Vertical field of view angle in degrees.
* @aspect: The (width over height) aspect ratio for display
* @z_near: The distance to the near clipping plane (Must be positive,
* and must not be 0)
* @z_far: The distance to the far clipping plane (Must be positive)
*
* Replaces the current matrix with a perspective matrix based on the
* provided values.
*
* <note>You should be careful not to have too great a @z_far / @z_near
* ratio since that will reduce the effectiveness of depth testing
* since there wont be enough precision to identify the depth of
* objects near to each other.</note>
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_perspective (CoglMatrixStack *stack,
float fov_y,
float aspect,
float z_near,
float z_far);
/**
* cogl_matrix_stack_orthographic:
* @stack: A #CoglMatrixStack
* @x_1: The x coordinate for the first vertical clipping plane
* @y_1: The y coordinate for the first horizontal clipping plane
* @x_2: The x coordinate for the second vertical clipping plane
* @y_2: The y coordinate for the second horizontal clipping plane
* @near: The <emphasis>distance</emphasis> to the near clipping
* plane (will be <emphasis>negative</emphasis> if the plane is
* behind the viewer)
* @far: The <emphasis>distance</emphasis> to the far clipping
* plane (will be <emphasis>negative</emphasis> if the plane is
* behind the viewer)
*
* Replaces the current matrix with an orthographic projection matrix.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_orthographic (CoglMatrixStack *stack,
float x_1,
float y_1,
float x_2,
float y_2,
float near,
float far);
/**
* cogl_matrix_stack_get_inverse:
* @stack: A #CoglMatrixStack
* @inverse: (out): The destination for a 4x4 inverse transformation matrix
*
* Gets the inverse transform of the current matrix and uses it to
* initialize a new #CoglMatrix.
*
* Return value: %TRUE if the inverse was successfully calculated or %FALSE
* for degenerate transformations that can't be inverted (in this case the
* @inverse matrix will simply be initialized with the identity matrix)
*/
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_get_inverse (CoglMatrixStack *stack,
CoglMatrix *inverse);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_get_entry:
* @stack: A #CoglMatrixStack
*
* Gets a reference to the current transform represented by a
* #CoglMatrixEntry pointer.
*
* <note>The transform represented by a #CoglMatrixEntry is
* immutable.</note>
*
* <note>#CoglMatrixEntry<!-- -->s are reference counted using
* cogl_matrix_entry_ref() and cogl_matrix_entry_unref() and you
* should call cogl_matrix_entry_unref() when you are finished with
* and entry you get via cogl_matrix_stack_get_entry().</note>
*
* Return value: (transfer none): A pointer to the #CoglMatrixEntry
* representing the current matrix stack transform.
*/
CoglMatrixEntry *
cogl_matrix_stack_get_entry (CoglMatrixStack *stack);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_get:
* @stack: A #CoglMatrixStack
* @matrix: (out): The potential destination for the current matrix
*
* Resolves the current @stack transform into a #CoglMatrix by
* combining the operations that have been applied to build up the
* current transform.
*
* There are two possible ways that this function may return its
* result depending on whether the stack is able to directly point
* to an internal #CoglMatrix or whether the result needs to be
* composed of multiple operations.
*
* If an internal matrix contains the required result then this
* function will directly return a pointer to that matrix, otherwise
* if the function returns %NULL then @matrix will be initialized
* to match the current transform of @stack.
*
* <note>@matrix will be left untouched if a direct pointer is
* returned.</note>
*
* Return value: A direct pointer to the current transform or %NULL
* and in that case @matrix will be initialized with
* the value of the current transform.
*/
CoglMatrix *
cogl_matrix_stack_get (CoglMatrixStack *stack,
CoglMatrix *matrix);
/**
* cogl_matrix_entry_get:
* @entry: A #CoglMatrixEntry
* @matrix: (out): The potential destination for the transform as
* a matrix
*
* Resolves the current @entry transform into a #CoglMatrix by
* combining the sequence of operations that have been applied to
* build up the current transform.
*
* There are two possible ways that this function may return its
* result depending on whether it's possible to directly point
* to an internal #CoglMatrix or whether the result needs to be
* composed of multiple operations.
*
* If an internal matrix contains the required result then this
* function will directly return a pointer to that matrix, otherwise
* if the function returns %NULL then @matrix will be initialized
* to match the transform of @entry.
*
* <note>@matrix will be left untouched if a direct pointer is
* returned.</note>
*
* Return value: A direct pointer to a #CoglMatrix transform or %NULL
* and in that case @matrix will be initialized with
* the effective transform represented by @entry.
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglMatrix *
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_entry_get (CoglMatrixEntry *entry,
CoglMatrix *matrix);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_stack_set:
* @stack: A #CoglMatrixStack
* @matrix: A #CoglMatrix replace the current matrix value with
*
* Replaces the current @stack matrix value with the value of @matrix.
* This effectively discards any other operations that were applied
* since the last time cogl_matrix_stack_push() was called or since
* the stack was initialized.
*/
matrix-stack: Make header style consistent Cogl doesn't follow the Clutter/GTK+ columnized function prototype style so this updates cogl-matrix-stack.h to match the other Cogl headers.
2010-12-10 06:34:02 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_stack_set (CoglMatrixStack *stack,
const CoglMatrix *matrix);
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_is_matrix_stack:
* @object: a #CoglObject
*
* Determines if the given #CoglObject refers to a #CoglMatrixStack.
*
* Return value: %TRUE if @object is a #CoglMatrixStack, otherwise
* %FALSE.
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglBool
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_is_matrix_stack (void *object);
/**
* cogl_matrix_entry_calculate_translation:
* @entry0: The first reference transform
* @entry1: A second reference transform
* @x: (out): The destination for the x-component of the translation
* @y: (out): The destination for the y-component of the translation
* @z: (out): The destination for the z-component of the translation
*
* Determines if the only difference between two transforms is a
* translation and if so returns what the @x, @y, and @z components of
* the translation are.
*
* If the difference between the two translations involves anything
* other than a translation then the function returns %FALSE.
*
* Return value: %TRUE if the only difference between the transform of
* @entry0 and the transform of @entry1 is a translation,
* otherwise %FALSE.
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglBool
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_entry_calculate_translation (CoglMatrixEntry *entry0,
CoglMatrixEntry *entry1,
float *x,
float *y,
float *z);
/**
* cogl_matrix_entry_is_identity:
* @entry: A #CoglMatrixEntry
*
* Determines whether @entry is known to represent an identity
* transform.
*
* If this returns %TRUE then the entry is definitely the identity
* matrix. If it returns %FALSE it may or may not be the identity
* matrix but no expensive comparison is performed to verify it.
*
* Return value: %TRUE if @entry is definitely an identity transform,
* otherwise %FALSE.
*/
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_entry_is_identity (CoglMatrixEntry *entry);
cogl-matrix-stack: Add _cogl_matrix_stack_has_identity_flag This adds an internal function to quickly determine whether the top of the matrix stack is known to be the identity matrix.
2010-12-10 12:42:39 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_entry_equal:
* @entry0: The first #CoglMatrixEntry to compare
* @entry1: A second #CoglMatrixEntry to compare
*
* Compares two arbitrary #CoglMatrixEntry transforms for equality
* returning %TRUE if they are equal or %FALSE otherwise.
*
* <note>In many cases it is unnecessary to use this api and instead
* direct pointer comparisons of entries are good enough and much
* cheaper too.</note>
*
* Return value: %TRUE if @entry0 represents the same transform as
* @entry1, otherwise %FALSE.
*/
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_entry_equal (CoglMatrixEntry *entry0,
CoglMatrixEntry *entry1);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_debug_matrix_entry_print:
* @entry: A #CoglMatrixEntry
*
* Allows visualizing the operations that build up the given @entry
* for debugging purposes by printing to stdout.
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_debug_matrix_entry_print (CoglMatrixEntry *entry);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_entry_ref:
* @entry: A #CoglMatrixEntry
*
* Takes a reference on the given @entry to ensure the @entry stays
* alive and remains valid. When you are finished with the @entry then
* you should call cogl_matrix_entry_unref().
*
* It is an error to pass an @entry pointer to cogl_object_ref() and
* cogl_object_unref()
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglMatrixEntry *
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_entry_ref (CoglMatrixEntry *entry);
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
/**
* cogl_matrix_entry_unref:
* @entry: A #CoglMatrixEntry
*
* Releases a reference on @entry either taken by calling
* cogl_matrix_entry_unref() or to release the reference given when
* calling cogl_matrix_stack_get_entry().
*/
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
cogl_matrix_entry_unref (CoglMatrixEntry *entry);
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 13:21:28 -05:00
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
#endif /* _COGL_MATRIX_STACK_H_ */
Reference in New Issue Copy Permalink