2008-06-23 10:57:36 -04:00
|
|
|
/*
|
2009-04-27 10:48:12 -04:00
|
|
|
* Cogl
|
2008-06-23 10:57:36 -04:00
|
|
|
*
|
2009-04-27 10:48:12 -04:00
|
|
|
* An object oriented GL/GLES Abstraction/Utility Layer
|
2008-06-23 10:57:36 -04:00
|
|
|
*
|
2010-04-14 14:41:08 -04:00
|
|
|
* Copyright (C) 2007,2008,2009,2010 Intel Corporation.
|
2008-06-23 10:57:36 -04: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
|
2010-03-01 07:56:10 -05:00
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
*
|
2008-06-23 10:57:36 -04:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
#include "config.h"
|
|
|
|
#endif
|
|
|
|
|
2008-12-04 08:45:09 -05:00
|
|
|
#include <string.h>
|
2009-11-04 14:42:17 -05:00
|
|
|
#include <math.h>
|
2009-05-08 11:32:01 -04:00
|
|
|
|
|
|
|
#include <glib.h>
|
|
|
|
|
2008-06-23 10:57:36 -04:00
|
|
|
#include "cogl-clip-stack.h"
|
2008-12-04 08:45:09 -05:00
|
|
|
#include "cogl-primitives.h"
|
2010-11-04 18:25:52 -04:00
|
|
|
#include "cogl-context-private.h"
|
2009-05-08 11:32:01 -04:00
|
|
|
#include "cogl-internal.h"
|
2009-11-26 14:06:35 -05:00
|
|
|
#include "cogl-framebuffer-private.h"
|
2010-02-10 13:18:30 -05:00
|
|
|
#include "cogl-journal-private.h"
|
2010-02-17 10:58:32 -05:00
|
|
|
#include "cogl-util.h"
|
2010-04-08 12:43:27 -04:00
|
|
|
#include "cogl-path-private.h"
|
2010-04-22 09:33:47 -04:00
|
|
|
#include "cogl-matrix-private.h"
|
2010-11-02 13:15:06 -04:00
|
|
|
#include "cogl-primitives-private.h"
|
2011-09-14 07:17:09 -04:00
|
|
|
#include "cogl-private.h"
|
2011-10-01 12:55:41 -04:00
|
|
|
#include "cogl-pipeline-opengl-private.h"
|
2011-10-03 09:39:05 -04:00
|
|
|
#include "cogl-attribute-private.h"
|
|
|
|
#include "cogl-primitive-private.h"
|
2012-02-17 16:46:39 -05:00
|
|
|
#include "cogl1-context.h"
|
2012-02-17 20:19:17 -05:00
|
|
|
#include "cogl-offscreen.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
|
|
|
#include "cogl-matrix-stack.h"
|
2008-06-23 10:57:36 -04:00
|
|
|
|
2010-12-05 13:02:05 -05:00
|
|
|
#ifndef GL_CLIP_PLANE0
|
|
|
|
#define GL_CLIP_PLANE0 0x3000
|
|
|
|
#define GL_CLIP_PLANE1 0x3001
|
|
|
|
#define GL_CLIP_PLANE2 0x3002
|
|
|
|
#define GL_CLIP_PLANE3 0x3003
|
|
|
|
#define GL_CLIP_PLANE4 0x3004
|
|
|
|
#define GL_CLIP_PLANE5 0x3005
|
|
|
|
#endif
|
|
|
|
|
2009-11-04 14:42:17 -05:00
|
|
|
static void
|
2010-11-22 10:51:15 -05:00
|
|
|
project_vertex (const CoglMatrix *modelview_projection,
|
2009-11-04 14:42:17 -05:00
|
|
|
float *vertex)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2010-11-22 10:51:15 -05:00
|
|
|
cogl_matrix_transform_point (modelview_projection,
|
2009-11-04 14:42:17 -05:00
|
|
|
&vertex[0], &vertex[1],
|
|
|
|
&vertex[2], &vertex[3]);
|
2010-11-22 10:51:15 -05:00
|
|
|
|
2009-11-04 14:42:17 -05:00
|
|
|
/* Convert from homogenized coordinates */
|
|
|
|
for (i = 0; i < 4; i++)
|
|
|
|
vertex[i] /= vertex[3];
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-08-03 12:06:10 -04:00
|
|
|
set_clip_plane (CoglFramebuffer *framebuffer,
|
|
|
|
GLint plane_num,
|
2009-11-04 14:42:17 -05:00
|
|
|
const float *vertex_a,
|
|
|
|
const float *vertex_b)
|
|
|
|
{
|
2011-07-07 15:44:56 -04:00
|
|
|
GLfloat planef[4];
|
|
|
|
double planed[4];
|
2009-11-04 14:42:17 -05:00
|
|
|
GLfloat angle;
|
|
|
|
CoglMatrixStack *modelview_stack =
|
2009-11-26 14:06:35 -05:00
|
|
|
_cogl_framebuffer_get_modelview_stack (framebuffer);
|
2009-11-04 14:42:17 -05:00
|
|
|
CoglMatrixStack *projection_stack =
|
2009-11-26 14:06:35 -05:00
|
|
|
_cogl_framebuffer_get_projection_stack (framebuffer);
|
2009-11-04 14:42:17 -05:00
|
|
|
CoglMatrix inverse_projection;
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
_cogl_matrix_stack_get_inverse (projection_stack, &inverse_projection);
|
|
|
|
|
|
|
|
/* Calculate the angle between the axes and the line crossing the
|
|
|
|
two points */
|
|
|
|
angle = atan2f (vertex_b[1] - vertex_a[1],
|
|
|
|
vertex_b[0] - vertex_a[0]) * (180.0/G_PI);
|
|
|
|
|
|
|
|
_cogl_matrix_stack_push (modelview_stack);
|
|
|
|
|
|
|
|
/* Load the inverse of the projection matrix so we can specify the plane
|
|
|
|
* in screen coordinates */
|
|
|
|
_cogl_matrix_stack_set (modelview_stack, &inverse_projection);
|
|
|
|
|
|
|
|
/* Rotate about point a */
|
|
|
|
_cogl_matrix_stack_translate (modelview_stack,
|
|
|
|
vertex_a[0], vertex_a[1], vertex_a[2]);
|
|
|
|
/* Rotate the plane by the calculated angle so that it will connect
|
|
|
|
the two points */
|
|
|
|
_cogl_matrix_stack_rotate (modelview_stack, angle, 0.0f, 0.0f, 1.0f);
|
|
|
|
_cogl_matrix_stack_translate (modelview_stack,
|
|
|
|
-vertex_a[0], -vertex_a[1], -vertex_a[2]);
|
|
|
|
|
2011-11-29 09:21:07 -05:00
|
|
|
/* Clip planes can only be used when a fixed function backend is in
|
|
|
|
use so we know we can directly push this matrix to the builtin
|
|
|
|
state */
|
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
|
|
|
_cogl_matrix_entry_flush_to_gl_builtins (ctx,
|
|
|
|
modelview_stack->last_entry,
|
2011-11-29 09:21:07 -05:00
|
|
|
COGL_MATRIX_MODELVIEW,
|
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
|
|
|
framebuffer,
|
2011-11-29 09:21:07 -05:00
|
|
|
FALSE /* don't disable flip */);
|
2009-11-04 14:42:17 -05:00
|
|
|
|
2011-07-07 15:44:56 -04:00
|
|
|
planef[0] = 0;
|
|
|
|
planef[1] = -1.0;
|
|
|
|
planef[2] = 0;
|
|
|
|
planef[3] = vertex_a[1];
|
|
|
|
|
|
|
|
switch (ctx->driver)
|
|
|
|
{
|
|
|
|
default:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case COGL_DRIVER_GLES1:
|
|
|
|
GE( ctx, glClipPlanef (plane_num, planef) );
|
|
|
|
break;
|
|
|
|
|
|
|
|
case COGL_DRIVER_GL:
|
|
|
|
planed[0] = planef[0];
|
|
|
|
planed[1] = planef[1];
|
|
|
|
planed[2] = planef[2];
|
|
|
|
planed[3] = planef[3];
|
|
|
|
GE( ctx, glClipPlane (plane_num, planed) );
|
|
|
|
break;
|
|
|
|
}
|
2009-11-04 14:42:17 -05:00
|
|
|
|
|
|
|
_cogl_matrix_stack_pop (modelview_stack);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-08-03 12:06:10 -04:00
|
|
|
set_clip_planes (CoglFramebuffer *framebuffer,
|
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 *modelview_entry,
|
2011-08-03 12:06:10 -04:00
|
|
|
float x_1,
|
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
|
|
|
float y_1,
|
|
|
|
float x_2,
|
|
|
|
float y_2)
|
2009-11-04 14:42:17 -05:00
|
|
|
{
|
|
|
|
CoglMatrix modelview_matrix;
|
|
|
|
CoglMatrixStack *projection_stack =
|
2009-11-26 14:06:35 -05:00
|
|
|
_cogl_framebuffer_get_projection_stack (framebuffer);
|
2009-11-04 14:42:17 -05:00
|
|
|
CoglMatrix projection_matrix;
|
2010-11-22 10:51:15 -05:00
|
|
|
CoglMatrix modelview_projection;
|
2010-04-20 09:58:57 -04:00
|
|
|
float signed_area;
|
2009-11-04 14:42:17 -05:00
|
|
|
|
2009-11-04 15:17:56 -05:00
|
|
|
float vertex_tl[4] = { x_1, y_1, 0, 1.0 };
|
|
|
|
float vertex_tr[4] = { x_2, y_1, 0, 1.0 };
|
|
|
|
float vertex_bl[4] = { x_1, y_2, 0, 1.0 };
|
|
|
|
float vertex_br[4] = { x_2, y_2, 0, 1.0 };
|
2009-11-04 14:42:17 -05:00
|
|
|
|
|
|
|
_cogl_matrix_stack_get (projection_stack, &projection_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
|
|
|
_cogl_matrix_entry_get (modelview_entry, &modelview_matrix);
|
2009-11-04 14:42:17 -05:00
|
|
|
|
2010-11-22 10:51:15 -05:00
|
|
|
cogl_matrix_multiply (&modelview_projection,
|
|
|
|
&projection_matrix,
|
|
|
|
&modelview_matrix);
|
|
|
|
|
|
|
|
project_vertex (&modelview_projection, vertex_tl);
|
|
|
|
project_vertex (&modelview_projection, vertex_tr);
|
|
|
|
project_vertex (&modelview_projection, vertex_bl);
|
|
|
|
project_vertex (&modelview_projection, vertex_br);
|
2009-11-04 14:42:17 -05:00
|
|
|
|
2010-04-20 09:58:57 -04:00
|
|
|
/* Calculate the signed area of the polygon formed by the four
|
|
|
|
vertices so that we can know its orientation */
|
|
|
|
signed_area = (vertex_tl[0] * (vertex_tr[1] - vertex_bl[1])
|
|
|
|
+ vertex_tr[0] * (vertex_br[1] - vertex_tl[1])
|
|
|
|
+ vertex_br[0] * (vertex_bl[1] - vertex_tr[1])
|
|
|
|
+ vertex_bl[0] * (vertex_tl[1] - vertex_br[1]));
|
|
|
|
|
|
|
|
/* Set the clip planes to form lines between all of the vertices
|
|
|
|
using the same orientation as we calculated */
|
|
|
|
if (signed_area > 0.0f)
|
2009-11-04 14:42:17 -05:00
|
|
|
{
|
2010-04-20 09:58:57 -04:00
|
|
|
/* counter-clockwise */
|
2011-08-03 12:06:10 -04:00
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE0, vertex_tl, vertex_bl);
|
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE1, vertex_bl, vertex_br);
|
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE2, vertex_br, vertex_tr);
|
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE3, vertex_tr, vertex_tl);
|
2010-04-20 09:58:57 -04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* clockwise */
|
2011-08-03 12:06:10 -04:00
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE0, vertex_tl, vertex_tr);
|
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE1, vertex_tr, vertex_br);
|
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE2, vertex_br, vertex_bl);
|
|
|
|
set_clip_plane (framebuffer, GL_CLIP_PLANE3, vertex_bl, vertex_tl);
|
2009-11-04 14:42:17 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-27 08:28:43 -04:00
|
|
|
static void
|
2011-08-03 12:06:10 -04:00
|
|
|
add_stencil_clip_rectangle (CoglFramebuffer *framebuffer,
|
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 *modelview_entry,
|
2011-08-03 12:06:10 -04:00
|
|
|
float x_1,
|
2009-11-04 15:17:56 -05:00
|
|
|
float y_1,
|
|
|
|
float x_2,
|
|
|
|
float y_2,
|
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 first)
|
2009-11-04 14:42:17 -05:00
|
|
|
{
|
2010-11-02 13:15:06 -04:00
|
|
|
CoglMatrixStack *projection_stack =
|
|
|
|
_cogl_framebuffer_get_projection_stack (framebuffer);
|
2011-11-21 09:22:01 -05:00
|
|
|
CoglContext *ctx = cogl_framebuffer_get_context (framebuffer);
|
2009-11-04 14:42:17 -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
|
|
|
/* NB: This can be called while flushing the journal so we need
|
|
|
|
* to be very conservative with what state we change.
|
|
|
|
*/
|
|
|
|
|
|
|
|
_cogl_context_set_current_projection_entry (ctx,
|
|
|
|
projection_stack->last_entry);
|
|
|
|
_cogl_context_set_current_modelview_entry (ctx, modelview_entry);
|
2011-01-24 12:32:06 -05:00
|
|
|
|
2009-11-04 14:42:17 -05:00
|
|
|
if (first)
|
|
|
|
{
|
2011-07-06 16:51:00 -04:00
|
|
|
GE( ctx, glEnable (GL_STENCIL_TEST) );
|
2009-11-04 14:42:17 -05:00
|
|
|
|
|
|
|
/* Initially disallow everything */
|
2011-07-06 16:51:00 -04:00
|
|
|
GE( ctx, glClearStencil (0) );
|
|
|
|
GE( ctx, glClear (GL_STENCIL_BUFFER_BIT) );
|
2009-11-04 14:42:17 -05:00
|
|
|
|
|
|
|
/* Punch out a hole to allow the rectangle */
|
2011-07-06 16:51:00 -04:00
|
|
|
GE( ctx, glStencilFunc (GL_NEVER, 0x1, 0x1) );
|
|
|
|
GE( ctx, glStencilOp (GL_REPLACE, GL_REPLACE, GL_REPLACE) );
|
2009-11-04 14:42:17 -05:00
|
|
|
|
2012-01-07 21:59:04 -05:00
|
|
|
_cogl_rectangle_immediate (framebuffer,
|
|
|
|
ctx->stencil_pipeline,
|
|
|
|
x_1, y_1, x_2, y_2);
|
2009-11-04 14:42:17 -05:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Add one to every pixel of the stencil buffer in the
|
|
|
|
rectangle */
|
2011-07-06 16:51:00 -04:00
|
|
|
GE( ctx, glStencilFunc (GL_NEVER, 0x1, 0x3) );
|
|
|
|
GE( ctx, glStencilOp (GL_INCR, GL_INCR, GL_INCR) );
|
2012-01-07 21:59:04 -05:00
|
|
|
_cogl_rectangle_immediate (framebuffer,
|
|
|
|
ctx->stencil_pipeline,
|
|
|
|
x_1, y_1, x_2, y_2);
|
2009-11-04 14:42:17 -05:00
|
|
|
|
|
|
|
/* Subtract one from all pixels in the stencil buffer so that
|
|
|
|
only pixels where both the original stencil buffer and the
|
|
|
|
rectangle are set will be valid */
|
2011-07-06 16:51:00 -04:00
|
|
|
GE( ctx, glStencilOp (GL_DECR, GL_DECR, GL_DECR) );
|
2009-11-04 14:42:17 -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
|
|
|
_cogl_context_set_current_projection_entry (ctx, &ctx->identity_entry);
|
|
|
|
_cogl_context_set_current_modelview_entry (ctx, &ctx->identity_entry);
|
2010-11-02 13:15:06 -04:00
|
|
|
|
2012-01-07 21:59:04 -05:00
|
|
|
_cogl_rectangle_immediate (framebuffer,
|
|
|
|
ctx->stencil_pipeline,
|
|
|
|
-1.0, -1.0, 1.0, 1.0);
|
2009-11-04 14:42:17 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Restore the stencil mode */
|
2011-07-06 16:51:00 -04:00
|
|
|
GE( ctx, glStencilFunc (GL_EQUAL, 0x1, 0x1) );
|
|
|
|
GE( ctx, glStencilOp (GL_KEEP, GL_KEEP, GL_KEEP) );
|
2009-11-04 14:42:17 -05:00
|
|
|
}
|
|
|
|
|
2012-04-18 10:57:33 -04:00
|
|
|
typedef void (*SilhouettePaintCallback) (CoglFramebuffer *framebuffer,
|
|
|
|
CoglPipeline *pipeline,
|
|
|
|
void *user_data);
|
2011-10-03 09:39:05 -04:00
|
|
|
|
2011-10-01 12:55:41 -04:00
|
|
|
static void
|
2011-10-03 09:39:05 -04:00
|
|
|
add_stencil_clip_silhouette (CoglFramebuffer *framebuffer,
|
|
|
|
SilhouettePaintCallback silhouette_callback,
|
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 *modelview_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
float bounds_x1,
|
|
|
|
float bounds_y1,
|
|
|
|
float bounds_x2,
|
|
|
|
float bounds_y2,
|
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 merge,
|
|
|
|
CoglBool need_clear,
|
2011-10-03 09:39:05 -04:00
|
|
|
void *user_data)
|
2011-10-01 12:55:41 -04:00
|
|
|
{
|
|
|
|
CoglMatrixStack *projection_stack =
|
|
|
|
_cogl_framebuffer_get_projection_stack (framebuffer);
|
|
|
|
CoglContext *ctx = cogl_framebuffer_get_context (framebuffer);
|
|
|
|
|
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
|
|
|
/* NB: This can be called while flushing the journal so we need
|
|
|
|
* to be very conservative with what state we change.
|
|
|
|
*/
|
|
|
|
|
|
|
|
_cogl_context_set_current_projection_entry (ctx,
|
|
|
|
projection_stack->last_entry);
|
|
|
|
_cogl_context_set_current_modelview_entry (ctx, modelview_entry);
|
2011-10-01 12:55:41 -04: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
|
|
|
_cogl_pipeline_flush_gl_state (ctx->stencil_pipeline, framebuffer, FALSE, 0);
|
2011-10-01 12:55:41 -04:00
|
|
|
|
|
|
|
GE( ctx, glEnable (GL_STENCIL_TEST) );
|
|
|
|
|
|
|
|
GE( ctx, glColorMask (FALSE, FALSE, FALSE, FALSE) );
|
|
|
|
GE( ctx, glDepthMask (FALSE) );
|
|
|
|
|
|
|
|
if (merge)
|
|
|
|
{
|
|
|
|
GE (ctx, glStencilMask (2));
|
|
|
|
GE (ctx, glStencilFunc (GL_LEQUAL, 0x2, 0x6));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* If we're not using the stencil buffer for clipping then we
|
|
|
|
don't need to clear the whole stencil buffer, just the area
|
|
|
|
that will be drawn */
|
|
|
|
if (need_clear)
|
|
|
|
/* If this is being called from the clip stack code then it
|
|
|
|
will have set up a scissor for the minimum bounding box of
|
|
|
|
all of the clips. That box will likely mean that this
|
|
|
|
_cogl_clear won't need to clear the entire
|
|
|
|
buffer. _cogl_framebuffer_clear_without_flush4f is used instead
|
|
|
|
of cogl_clear because it won't try to flush the journal */
|
|
|
|
_cogl_framebuffer_clear_without_flush4f (framebuffer,
|
|
|
|
COGL_BUFFER_BIT_STENCIL,
|
|
|
|
0, 0, 0, 0);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Just clear the bounding box */
|
|
|
|
GE( ctx, glStencilMask (~(GLuint) 0) );
|
|
|
|
GE( ctx, glStencilOp (GL_ZERO, GL_ZERO, GL_ZERO) );
|
2012-01-07 21:59:04 -05:00
|
|
|
_cogl_rectangle_immediate (framebuffer,
|
|
|
|
ctx->stencil_pipeline,
|
|
|
|
bounds_x1, bounds_y1,
|
2011-10-03 09:39:05 -04:00
|
|
|
bounds_x2, bounds_y2);
|
2011-10-01 12:55:41 -04:00
|
|
|
}
|
|
|
|
GE (ctx, glStencilMask (1));
|
|
|
|
GE (ctx, glStencilFunc (GL_LEQUAL, 0x1, 0x3));
|
|
|
|
}
|
|
|
|
|
|
|
|
GE (ctx, glStencilOp (GL_INVERT, GL_INVERT, GL_INVERT));
|
|
|
|
|
2012-04-18 10:57:33 -04:00
|
|
|
silhouette_callback (framebuffer, ctx->stencil_pipeline, user_data);
|
2011-10-01 12:55:41 -04:00
|
|
|
|
|
|
|
if (merge)
|
|
|
|
{
|
|
|
|
/* Now we have the new stencil buffer in bit 1 and the old
|
|
|
|
stencil buffer in bit 0 so we need to intersect them */
|
|
|
|
GE (ctx, glStencilMask (3));
|
|
|
|
GE (ctx, glStencilFunc (GL_NEVER, 0x2, 0x3));
|
|
|
|
GE (ctx, glStencilOp (GL_DECR, GL_DECR, GL_DECR));
|
|
|
|
/* Decrement all of the bits twice so that only pixels where the
|
|
|
|
value is 3 will remain */
|
|
|
|
|
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
|
|
|
_cogl_context_set_current_projection_entry (ctx, &ctx->identity_entry);
|
|
|
|
_cogl_context_set_current_modelview_entry (ctx, &ctx->identity_entry);
|
2011-10-01 12:55:41 -04:00
|
|
|
|
2012-01-07 21:59:04 -05:00
|
|
|
_cogl_rectangle_immediate (framebuffer, ctx->stencil_pipeline,
|
|
|
|
-1.0, -1.0, 1.0, 1.0);
|
|
|
|
_cogl_rectangle_immediate (framebuffer, ctx->stencil_pipeline,
|
|
|
|
-1.0, -1.0, 1.0, 1.0);
|
2011-10-01 12:55:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
GE (ctx, glStencilMask (~(GLuint) 0));
|
|
|
|
GE (ctx, glDepthMask (TRUE));
|
|
|
|
GE (ctx, glColorMask (TRUE, TRUE, TRUE, TRUE));
|
|
|
|
|
|
|
|
GE (ctx, glStencilFunc (GL_EQUAL, 0x1, 0x1));
|
|
|
|
GE (ctx, glStencilOp (GL_KEEP, GL_KEEP, GL_KEEP));
|
|
|
|
}
|
|
|
|
|
2011-10-03 09:39:05 -04:00
|
|
|
static void
|
2012-04-18 10:57:33 -04:00
|
|
|
paint_path_silhouette (CoglFramebuffer *framebuffer,
|
|
|
|
CoglPipeline *pipeline,
|
|
|
|
void *user_data)
|
2011-10-03 09:39:05 -04:00
|
|
|
{
|
|
|
|
CoglPath *path = user_data;
|
|
|
|
if (path->data->path_nodes->len >= 3)
|
|
|
|
_cogl_path_fill_nodes (path,
|
2012-04-18 10:57:33 -04:00
|
|
|
framebuffer,
|
|
|
|
pipeline,
|
2011-10-03 09:39:05 -04:00
|
|
|
COGL_DRAW_SKIP_JOURNAL_FLUSH |
|
|
|
|
COGL_DRAW_SKIP_PIPELINE_VALIDATION |
|
|
|
|
COGL_DRAW_SKIP_FRAMEBUFFER_FLUSH);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
add_stencil_clip_path (CoglFramebuffer *framebuffer,
|
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 *modelview_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
CoglPath *path,
|
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 merge,
|
|
|
|
CoglBool need_clear)
|
2011-10-03 09:39:05 -04:00
|
|
|
{
|
|
|
|
CoglPathData *data = path->data;
|
|
|
|
add_stencil_clip_silhouette (framebuffer,
|
|
|
|
paint_path_silhouette,
|
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
|
|
|
modelview_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
data->path_nodes_min.x,
|
|
|
|
data->path_nodes_min.y,
|
|
|
|
data->path_nodes_max.x,
|
|
|
|
data->path_nodes_max.y,
|
|
|
|
merge,
|
|
|
|
need_clear,
|
|
|
|
path);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2012-04-18 10:57:33 -04:00
|
|
|
paint_primitive_silhouette (CoglFramebuffer *framebuffer,
|
|
|
|
CoglPipeline *pipeline,
|
|
|
|
void *user_data)
|
2011-10-03 09:39:05 -04:00
|
|
|
{
|
2012-04-18 10:57:33 -04:00
|
|
|
_cogl_framebuffer_draw_primitive (framebuffer,
|
|
|
|
pipeline,
|
2012-01-07 21:59:04 -05:00
|
|
|
user_data,
|
|
|
|
COGL_DRAW_SKIP_JOURNAL_FLUSH |
|
|
|
|
COGL_DRAW_SKIP_PIPELINE_VALIDATION |
|
|
|
|
COGL_DRAW_SKIP_FRAMEBUFFER_FLUSH |
|
|
|
|
COGL_DRAW_SKIP_LEGACY_STATE);
|
2011-10-03 09:39:05 -04:00
|
|
|
}
|
|
|
|
|
2012-03-06 13:21:28 -05:00
|
|
|
static void
|
2011-10-03 09:39:05 -04:00
|
|
|
add_stencil_clip_primitive (CoglFramebuffer *framebuffer,
|
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 *modelview_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
CoglPrimitive *primitive,
|
|
|
|
float bounds_x1,
|
|
|
|
float bounds_y1,
|
|
|
|
float bounds_x2,
|
|
|
|
float bounds_y2,
|
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 merge,
|
|
|
|
CoglBool need_clear)
|
2011-10-03 09:39:05 -04:00
|
|
|
{
|
|
|
|
add_stencil_clip_silhouette (framebuffer,
|
|
|
|
paint_primitive_silhouette,
|
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
|
|
|
modelview_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
bounds_x1,
|
|
|
|
bounds_y1,
|
|
|
|
bounds_x2,
|
|
|
|
bounds_y2,
|
|
|
|
merge,
|
|
|
|
need_clear,
|
|
|
|
primitive);
|
|
|
|
}
|
|
|
|
|
2009-11-04 14:42:17 -05:00
|
|
|
static void
|
|
|
|
disable_stencil_buffer (void)
|
|
|
|
{
|
2011-07-06 16:51:00 -04:00
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
GE( ctx, glDisable (GL_STENCIL_TEST) );
|
2009-11-04 14:42:17 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
enable_clip_planes (void)
|
|
|
|
{
|
2011-07-06 16:51:00 -04:00
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
GE( ctx, glEnable (GL_CLIP_PLANE0) );
|
|
|
|
GE( ctx, glEnable (GL_CLIP_PLANE1) );
|
|
|
|
GE( ctx, glEnable (GL_CLIP_PLANE2) );
|
|
|
|
GE( ctx, glEnable (GL_CLIP_PLANE3) );
|
2009-11-04 14:42:17 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
disable_clip_planes (void)
|
|
|
|
{
|
2011-07-06 16:51:00 -04:00
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
GE( ctx, glDisable (GL_CLIP_PLANE3) );
|
|
|
|
GE( ctx, glDisable (GL_CLIP_PLANE2) );
|
|
|
|
GE( ctx, glDisable (GL_CLIP_PLANE1) );
|
|
|
|
GE( ctx, glDisable (GL_CLIP_PLANE0) );
|
2009-11-04 14:42:17 -05:00
|
|
|
}
|
|
|
|
|
Switch use of primitive glib types to c99 equivalents
The coding style has for a long time said to avoid using redundant glib
data types such as gint or gchar etc because we feel that they make the
code look unnecessarily foreign to developers coming from outside of the
Gnome developer community.
Note: When we tried to find the historical rationale for the types we
just found that they were apparently only added for consistent syntax
highlighting which didn't seem that compelling.
Up until now we have been continuing to use some of the platform
specific type such as gint{8,16,32,64} and gsize but this patch switches
us over to using the standard c99 equivalents instead so we can further
ensure that our code looks familiar to the widest range of C developers
who might potentially contribute to Cogl.
So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this
switches all Cogl code to instead use the int{8,16,32,64}_t and
uint{8,16,32,64}_t c99 types instead.
Instead of gsize we now use size_t
For now we are not going to use the c99 _Bool type and instead we have
introduced a new CoglBool type to use instead of gboolean.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
|
|
|
static void *
|
2010-04-14 08:17:26 -04:00
|
|
|
_cogl_clip_stack_push_entry (CoglClipStack *clip_stack,
|
|
|
|
size_t size,
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStackType type)
|
2010-04-14 08:17:26 -04:00
|
|
|
{
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *entry = g_slice_alloc (size);
|
2010-04-14 08:17:26 -04:00
|
|
|
|
|
|
|
/* The new entry starts with a ref count of 1 because the stack
|
|
|
|
holds a reference to it as it is the top entry */
|
|
|
|
entry->ref_count = 1;
|
|
|
|
entry->type = type;
|
2010-11-01 15:52:45 -04:00
|
|
|
entry->parent = clip_stack;
|
2010-04-14 08:17:26 -04:00
|
|
|
|
|
|
|
/* We don't need to take a reference to the parent from the entry
|
2010-11-01 15:52:45 -04:00
|
|
|
because the we are stealing the ref in the new stack top */
|
2010-04-14 08:17:26 -04:00
|
|
|
|
|
|
|
return 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
|
|
|
static void
|
|
|
|
get_transformed_corners (float x_1,
|
|
|
|
float y_1,
|
|
|
|
float x_2,
|
|
|
|
float y_2,
|
|
|
|
CoglMatrix *modelview,
|
|
|
|
CoglMatrix *projection,
|
|
|
|
const float *viewport,
|
|
|
|
float *transformed_corners)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
transformed_corners[0] = x_1;
|
|
|
|
transformed_corners[1] = y_1;
|
|
|
|
transformed_corners[2] = x_2;
|
|
|
|
transformed_corners[3] = y_1;
|
|
|
|
transformed_corners[4] = x_2;
|
|
|
|
transformed_corners[5] = y_2;
|
|
|
|
transformed_corners[6] = x_1;
|
|
|
|
transformed_corners[7] = y_2;
|
|
|
|
|
|
|
|
|
|
|
|
/* Project the coordinates to window space coordinates */
|
|
|
|
for (i = 0; i < 4; i++)
|
|
|
|
{
|
|
|
|
float *v = transformed_corners + i * 2;
|
|
|
|
_cogl_transform_point (modelview, projection, viewport, v, v + 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-04-22 09:33:47 -04:00
|
|
|
/* Sets the window-space bounds of the entry based on the projected
|
|
|
|
coordinates of the given rectangle */
|
|
|
|
static void
|
2010-11-01 15:52:45 -04:00
|
|
|
_cogl_clip_stack_entry_set_bounds (CoglClipStack *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
|
|
|
float *transformed_corners)
|
2010-04-22 09:33:47 -04:00
|
|
|
{
|
|
|
|
float min_x = G_MAXFLOAT, min_y = G_MAXFLOAT;
|
|
|
|
float max_x = -G_MAXFLOAT, max_y = -G_MAXFLOAT;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 4; i++)
|
|
|
|
{
|
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
|
|
|
float *v = transformed_corners + i * 2;
|
2010-04-22 09:33:47 -04:00
|
|
|
|
|
|
|
if (v[0] > max_x)
|
|
|
|
max_x = v[0];
|
|
|
|
if (v[0] < min_x)
|
|
|
|
min_x = v[0];
|
|
|
|
if (v[1] > max_y)
|
|
|
|
max_y = v[1];
|
|
|
|
if (v[1] < min_y)
|
|
|
|
min_y = v[1];
|
|
|
|
}
|
|
|
|
|
|
|
|
entry->bounds_x0 = floorf (min_x);
|
|
|
|
entry->bounds_x1 = ceilf (max_x);
|
|
|
|
entry->bounds_y0 = floorf (min_y);
|
|
|
|
entry->bounds_y1 = ceilf (max_y);
|
|
|
|
}
|
|
|
|
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *
|
2010-05-27 20:01:28 -04:00
|
|
|
_cogl_clip_stack_push_window_rectangle (CoglClipStack *stack,
|
2010-04-14 14:41:08 -04:00
|
|
|
int x_offset,
|
|
|
|
int y_offset,
|
|
|
|
int width,
|
|
|
|
int height)
|
2009-05-08 11:32:01 -04:00
|
|
|
{
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *entry;
|
2009-05-08 11:32:01 -04:00
|
|
|
|
2010-04-14 08:17:26 -04:00
|
|
|
entry = _cogl_clip_stack_push_entry (stack,
|
2010-11-01 15:52:45 -04:00
|
|
|
sizeof (CoglClipStackWindowRect),
|
2010-04-14 08:17:26 -04:00
|
|
|
COGL_CLIP_STACK_WINDOW_RECT);
|
2009-05-08 11:32:01 -04:00
|
|
|
|
2010-04-22 09:33:47 -04:00
|
|
|
entry->bounds_x0 = x_offset;
|
|
|
|
entry->bounds_x1 = x_offset + width;
|
|
|
|
entry->bounds_y0 = y_offset;
|
|
|
|
entry->bounds_y1 = y_offset + height;
|
2010-11-01 15:52:45 -04:00
|
|
|
|
|
|
|
return entry;
|
2009-05-08 11:32:01 -04:00
|
|
|
}
|
|
|
|
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *
|
2010-05-27 20:01:28 -04:00
|
|
|
_cogl_clip_stack_push_rectangle (CoglClipStack *stack,
|
2010-04-14 14:41:08 -04:00
|
|
|
float x_1,
|
|
|
|
float y_1,
|
2009-11-04 15:17:56 -05:00
|
|
|
float x_2,
|
2010-04-14 14:41:08 -04:00
|
|
|
float y_2,
|
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 *modelview_entry,
|
|
|
|
CoglMatrixEntry *projection_entry,
|
|
|
|
const float *viewport)
|
2008-06-23 10:57:36 -04:00
|
|
|
{
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStackRect *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 modelview;
|
|
|
|
CoglMatrix projection;
|
|
|
|
CoglMatrix modelview_projection;
|
|
|
|
|
|
|
|
/* Corners of the given rectangle in an clockwise order:
|
|
|
|
* (0, 1) (2, 3)
|
|
|
|
*
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* (6, 7) (4, 5)
|
|
|
|
*/
|
|
|
|
float rect[] = {
|
|
|
|
x_1, y_1,
|
|
|
|
x_2, y_1,
|
|
|
|
x_2, y_2,
|
|
|
|
x_1, y_2
|
|
|
|
};
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2008-06-23 10:57:36 -04:00
|
|
|
/* Make a new entry */
|
2010-04-14 08:17:26 -04:00
|
|
|
entry = _cogl_clip_stack_push_entry (stack,
|
2010-11-01 15:52:45 -04:00
|
|
|
sizeof (CoglClipStackRect),
|
2010-04-14 08:17:26 -04:00
|
|
|
COGL_CLIP_STACK_RECT);
|
|
|
|
|
2009-11-04 15:17:56 -05:00
|
|
|
entry->x0 = x_1;
|
|
|
|
entry->y0 = y_1;
|
|
|
|
entry->x1 = x_2;
|
|
|
|
entry->y1 = y_2;
|
2008-06-23 10:57:36 -04: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
|
|
|
entry->matrix_entry = _cogl_matrix_entry_ref (modelview_entry);
|
|
|
|
|
|
|
|
_cogl_matrix_entry_get (modelview_entry, &modelview);
|
|
|
|
_cogl_matrix_entry_get (projection_entry, &projection);
|
2010-04-22 09:33:47 -04: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
|
|
|
cogl_matrix_multiply (&modelview_projection,
|
|
|
|
&projection,
|
|
|
|
&modelview);
|
|
|
|
|
|
|
|
/* Technically we could avoid the viewport transform at this point
|
|
|
|
* if we want to make this a bit faster. */
|
|
|
|
_cogl_transform_point (&modelview, &projection, viewport, &rect[0], &rect[1]);
|
|
|
|
_cogl_transform_point (&modelview, &projection, viewport, &rect[2], &rect[3]);
|
|
|
|
_cogl_transform_point (&modelview, &projection, viewport, &rect[4], &rect[5]);
|
|
|
|
_cogl_transform_point (&modelview, &projection, viewport, &rect[6], &rect[7]);
|
|
|
|
|
|
|
|
/* If the fully transformed rectangle isn't still axis aligned we
|
|
|
|
* can't handle it using a scissor.
|
2010-11-09 07:01:04 -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
|
|
|
* We don't use an epsilon here since we only really aim to catch
|
|
|
|
* simple cases where the transform doesn't leave the rectangle screen
|
|
|
|
* aligned and don't mind some false positives.
|
2010-11-09 07:01:04 -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
|
|
|
if (rect[0] != rect[6] ||
|
|
|
|
rect[1] != rect[3] ||
|
|
|
|
rect[2] != rect[4] ||
|
|
|
|
rect[7] != rect[5])
|
2010-11-09 07:01:04 -05:00
|
|
|
{
|
|
|
|
entry->can_be_scissor = 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
|
|
|
|
2010-11-09 07:01:04 -05:00
|
|
|
_cogl_clip_stack_entry_set_bounds ((CoglClipStack *) 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
|
|
|
rect);
|
2010-11-09 07:01:04 -05:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
CoglClipStack *base_entry = (CoglClipStack *) 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
|
|
|
x_1 = rect[0];
|
|
|
|
y_1 = rect[1];
|
|
|
|
x_2 = rect[4];
|
|
|
|
y_2 = rect[5];
|
2010-11-09 07:01:04 -05:00
|
|
|
|
|
|
|
/* Consider that the modelview matrix may flip the rectangle
|
|
|
|
* along the x or y axis... */
|
|
|
|
#define SWAP(A,B) do { float tmp = B; B = A; A = tmp; } while (0)
|
|
|
|
if (x_1 > x_2)
|
|
|
|
SWAP (x_1, x_2);
|
|
|
|
if (y_1 > y_2)
|
|
|
|
SWAP (y_1, y_2);
|
|
|
|
#undef SWAP
|
|
|
|
|
|
|
|
base_entry->bounds_x0 = COGL_UTIL_NEARBYINT (x_1);
|
|
|
|
base_entry->bounds_y0 = COGL_UTIL_NEARBYINT (y_1);
|
|
|
|
base_entry->bounds_x1 = COGL_UTIL_NEARBYINT (x_2);
|
|
|
|
base_entry->bounds_y1 = COGL_UTIL_NEARBYINT (y_2);
|
|
|
|
entry->can_be_scissor = TRUE;
|
|
|
|
}
|
2010-11-01 15:52:45 -04:00
|
|
|
|
|
|
|
return (CoglClipStack *) entry;
|
2009-11-04 15:17:56 -05:00
|
|
|
}
|
|
|
|
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *
|
2010-05-27 20:01:28 -04:00
|
|
|
_cogl_clip_stack_push_from_path (CoglClipStack *stack,
|
|
|
|
CoglPath *path,
|
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 *modelview_entry,
|
|
|
|
CoglMatrixEntry *projection_entry,
|
|
|
|
const float *viewport)
|
2008-12-04 08:45:09 -05:00
|
|
|
{
|
2010-04-22 09:33:47 -04:00
|
|
|
float x_1, y_1, x_2, y_2;
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2011-03-09 12:46:23 -05:00
|
|
|
_cogl_path_get_bounds (path, &x_1, &y_1, &x_2, &y_2);
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2011-03-09 12:46:23 -05:00
|
|
|
/* If the path is a simple rectangle then we can divert to pushing a
|
|
|
|
rectangle clip instead which usually won't involve the stencil
|
|
|
|
buffer */
|
|
|
|
if (_cogl_path_is_rectangle (path))
|
|
|
|
return _cogl_clip_stack_push_rectangle (stack,
|
|
|
|
x_1, y_1,
|
|
|
|
x_2, y_2,
|
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
|
|
|
modelview_entry,
|
|
|
|
projection_entry,
|
|
|
|
viewport);
|
2011-03-09 12:46:23 -05:00
|
|
|
else
|
|
|
|
{
|
|
|
|
CoglClipStackPath *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 modelview;
|
|
|
|
CoglMatrix projection;
|
|
|
|
float transformed_corners[8];
|
2008-06-23 10:57:36 -04:00
|
|
|
|
2011-03-09 12:46:23 -05:00
|
|
|
entry = _cogl_clip_stack_push_entry (stack,
|
|
|
|
sizeof (CoglClipStackPath),
|
|
|
|
COGL_CLIP_STACK_PATH);
|
2010-04-22 09:33:47 -04:00
|
|
|
|
2011-03-09 12:46:23 -05:00
|
|
|
entry->path = cogl_path_copy (path);
|
2010-04-22 09:33:47 -04: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
|
|
|
entry->matrix_entry = _cogl_matrix_entry_ref (modelview_entry);
|
2010-11-01 15:52:45 -04: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
|
|
|
_cogl_matrix_entry_get (modelview_entry, &modelview);
|
|
|
|
_cogl_matrix_entry_get (projection_entry, &projection);
|
|
|
|
|
|
|
|
get_transformed_corners (x_1, y_1, x_2, y_2,
|
|
|
|
&modelview,
|
|
|
|
&projection,
|
|
|
|
viewport,
|
|
|
|
transformed_corners);
|
2011-03-09 12:46:23 -05:00
|
|
|
_cogl_clip_stack_entry_set_bounds ((CoglClipStack *) 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
|
|
|
transformed_corners);
|
2011-03-09 12:46:23 -05:00
|
|
|
|
|
|
|
return (CoglClipStack *) entry;
|
|
|
|
}
|
2008-06-23 10:57:36 -04:00
|
|
|
}
|
|
|
|
|
2011-10-03 09:39:05 -04:00
|
|
|
CoglClipStack *
|
|
|
|
_cogl_clip_stack_push_primitive (CoglClipStack *stack,
|
|
|
|
CoglPrimitive *primitive,
|
|
|
|
float bounds_x1,
|
|
|
|
float bounds_y1,
|
|
|
|
float bounds_x2,
|
|
|
|
float bounds_y2,
|
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 *modelview_entry,
|
|
|
|
CoglMatrixEntry *projection_entry,
|
|
|
|
const float *viewport)
|
2011-10-03 09:39:05 -04:00
|
|
|
{
|
|
|
|
CoglClipStackPrimitive *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 modelview;
|
|
|
|
CoglMatrix projection;
|
|
|
|
float transformed_corners[8];
|
2011-10-03 09:39:05 -04:00
|
|
|
|
|
|
|
entry = _cogl_clip_stack_push_entry (stack,
|
|
|
|
sizeof (CoglClipStackPrimitive),
|
|
|
|
COGL_CLIP_STACK_PRIMITIVE);
|
|
|
|
|
|
|
|
entry->primitive = cogl_object_ref (primitive);
|
|
|
|
|
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
|
|
|
entry->matrix_entry = _cogl_matrix_entry_ref (modelview_entry);
|
2011-10-03 09:39:05 -04:00
|
|
|
|
|
|
|
entry->bounds_x1 = bounds_x1;
|
|
|
|
entry->bounds_y1 = bounds_y1;
|
|
|
|
entry->bounds_x2 = bounds_x2;
|
|
|
|
entry->bounds_y2 = bounds_y2;
|
|
|
|
|
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
|
|
|
_cogl_matrix_entry_get (modelview_entry, &modelview);
|
|
|
|
_cogl_matrix_entry_get (modelview_entry, &projection);
|
|
|
|
|
|
|
|
get_transformed_corners (bounds_x1, bounds_y1, bounds_x2, bounds_y2,
|
|
|
|
&modelview,
|
|
|
|
&projection,
|
|
|
|
viewport,
|
|
|
|
transformed_corners);
|
|
|
|
|
2011-10-03 09:39:05 -04:00
|
|
|
/* NB: this is referring to the bounds in window coordinates as opposed
|
|
|
|
* to the bounds above in primitive local coordinates. */
|
|
|
|
_cogl_clip_stack_entry_set_bounds ((CoglClipStack *) 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
|
|
|
transformed_corners);
|
2011-10-03 09:39:05 -04:00
|
|
|
|
|
|
|
return (CoglClipStack *) entry;
|
|
|
|
}
|
|
|
|
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *
|
|
|
|
_cogl_clip_stack_ref (CoglClipStack *entry)
|
|
|
|
{
|
|
|
|
/* A NULL pointer is considered a valid stack so we should accept
|
|
|
|
that as an argument */
|
|
|
|
if (entry)
|
|
|
|
entry->ref_count++;
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
_cogl_clip_stack_unref (CoglClipStack *entry)
|
2010-04-14 08:17:26 -04:00
|
|
|
{
|
|
|
|
/* Unref all of the entries until we hit the root of the list or the
|
|
|
|
entry still has a remaining reference */
|
|
|
|
while (entry && --entry->ref_count <= 0)
|
|
|
|
{
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *parent = entry->parent;
|
2010-04-14 08:17:26 -04:00
|
|
|
|
|
|
|
switch (entry->type)
|
|
|
|
{
|
|
|
|
case COGL_CLIP_STACK_RECT:
|
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
|
|
|
{
|
|
|
|
CoglClipStackRect *rect = (CoglClipStackRect *) entry;
|
|
|
|
_cogl_matrix_entry_unref (rect->matrix_entry);
|
|
|
|
g_slice_free1 (sizeof (CoglClipStackRect), entry);
|
|
|
|
break;
|
|
|
|
}
|
2010-04-14 08:17:26 -04:00
|
|
|
case COGL_CLIP_STACK_WINDOW_RECT:
|
2010-11-01 15:52:45 -04:00
|
|
|
g_slice_free1 (sizeof (CoglClipStackWindowRect), entry);
|
2010-04-14 08:17:26 -04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case COGL_CLIP_STACK_PATH:
|
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
|
|
|
{
|
|
|
|
CoglClipStackPath *path_entry = (CoglClipStackPath *) entry;
|
|
|
|
_cogl_matrix_entry_unref (path_entry->matrix_entry);
|
|
|
|
cogl_object_unref (path_entry->path);
|
|
|
|
g_slice_free1 (sizeof (CoglClipStackPath), entry);
|
|
|
|
break;
|
|
|
|
}
|
2011-10-03 09:39:05 -04:00
|
|
|
case COGL_CLIP_STACK_PRIMITIVE:
|
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
|
|
|
{
|
|
|
|
CoglClipStackPrimitive *primitive_entry =
|
|
|
|
(CoglClipStackPrimitive *) entry;
|
|
|
|
_cogl_matrix_entry_unref (primitive_entry->matrix_entry);
|
|
|
|
cogl_object_unref (primitive_entry->primitive);
|
|
|
|
g_slice_free1 (sizeof (CoglClipStackPrimitive), entry);
|
|
|
|
break;
|
|
|
|
}
|
2010-04-14 08:17:26 -04:00
|
|
|
default:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
}
|
|
|
|
|
|
|
|
entry = parent;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *
|
2010-05-27 20:01:28 -04:00
|
|
|
_cogl_clip_stack_pop (CoglClipStack *stack)
|
2008-06-23 10:57:36 -04:00
|
|
|
{
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *new_top;
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2011-10-13 17:34:30 -04:00
|
|
|
_COGL_RETURN_VAL_IF_FAIL (stack != NULL, NULL);
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2010-04-14 08:17:26 -04:00
|
|
|
/* To pop we are moving the top of the stack to the old top's parent
|
|
|
|
node. The stack always needs to have a reference to the top entry
|
|
|
|
so we must take a reference to the new top. The stack would have
|
|
|
|
previously had a reference to the old top so we need to decrease
|
|
|
|
the ref count on that. We need to ref the new head first in case
|
|
|
|
this stack was the only thing referencing the old top. In that
|
|
|
|
case the call to _cogl_clip_stack_entry_unref will unref the
|
|
|
|
parent. */
|
2010-11-01 15:52:45 -04:00
|
|
|
new_top = stack->parent;
|
|
|
|
|
|
|
|
_cogl_clip_stack_ref (new_top);
|
|
|
|
|
|
|
|
_cogl_clip_stack_unref (stack);
|
|
|
|
|
|
|
|
return new_top;
|
2008-06-23 10:57:36 -04:00
|
|
|
}
|
|
|
|
|
2011-01-12 14:13:45 -05:00
|
|
|
void
|
|
|
|
_cogl_clip_stack_get_bounds (CoglClipStack *stack,
|
|
|
|
int *scissor_x0,
|
|
|
|
int *scissor_y0,
|
|
|
|
int *scissor_x1,
|
|
|
|
int *scissor_y1)
|
|
|
|
{
|
|
|
|
CoglClipStack *entry;
|
|
|
|
|
|
|
|
*scissor_x0 = 0;
|
|
|
|
*scissor_y0 = 0;
|
|
|
|
*scissor_x1 = G_MAXINT;
|
|
|
|
*scissor_y1 = G_MAXINT;
|
|
|
|
|
|
|
|
for (entry = stack; entry; entry = entry->parent)
|
|
|
|
{
|
|
|
|
/* Get the intersection of the current scissor and the bounding
|
|
|
|
box of this clip */
|
|
|
|
*scissor_x0 = MAX (*scissor_x0, entry->bounds_x0);
|
|
|
|
*scissor_y0 = MAX (*scissor_y0, entry->bounds_y0);
|
|
|
|
*scissor_x1 = MIN (*scissor_x1, entry->bounds_x1);
|
|
|
|
*scissor_y1 = MIN (*scissor_y1, entry->bounds_y1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-06-23 10:57:36 -04:00
|
|
|
void
|
2011-08-03 12:06:10 -04:00
|
|
|
_cogl_clip_stack_flush (CoglClipStack *stack,
|
|
|
|
CoglFramebuffer *framebuffer)
|
2008-06-23 10:57:36 -04: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
|
|
|
CoglContext *ctx = framebuffer->context;
|
2009-09-25 09:34:34 -04:00
|
|
|
int has_clip_planes;
|
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 using_clip_planes = FALSE;
|
|
|
|
CoglBool using_stencil_buffer = FALSE;
|
2011-01-12 14:13:45 -05:00
|
|
|
int scissor_x0;
|
|
|
|
int scissor_y0;
|
|
|
|
int scissor_x1;
|
|
|
|
int scissor_y1;
|
2010-11-01 15:52:45 -04:00
|
|
|
CoglClipStack *entry;
|
2010-04-22 09:33:47 -04:00
|
|
|
int scissor_y_start;
|
2008-06-23 10:57:36 -04:00
|
|
|
|
2010-11-02 10:28:12 -04:00
|
|
|
/* If we have already flushed this state then we don't need to do
|
|
|
|
anything */
|
|
|
|
if (ctx->current_clip_stack_valid)
|
|
|
|
{
|
|
|
|
if (ctx->current_clip_stack == stack)
|
|
|
|
return;
|
|
|
|
|
|
|
|
_cogl_clip_stack_unref (ctx->current_clip_stack);
|
|
|
|
}
|
|
|
|
|
|
|
|
ctx->current_clip_stack_valid = TRUE;
|
|
|
|
ctx->current_clip_stack = _cogl_clip_stack_ref (stack);
|
|
|
|
|
2011-10-13 04:24:58 -04:00
|
|
|
has_clip_planes =
|
|
|
|
ctx->private_feature_flags & COGL_PRIVATE_FEATURE_FOUR_CLIP_PLANES;
|
2009-09-25 09:34:34 -04:00
|
|
|
|
2010-06-08 13:38:25 -04:00
|
|
|
if (has_clip_planes)
|
|
|
|
disable_clip_planes ();
|
2009-11-04 14:42:17 -05:00
|
|
|
disable_stencil_buffer ();
|
2009-02-12 06:08:00 -05:00
|
|
|
|
2008-12-04 08:45:09 -05:00
|
|
|
/* If the stack is empty then there's nothing else to do */
|
2010-11-01 15:52:45 -04:00
|
|
|
if (stack == NULL)
|
2010-05-06 09:15:04 -04:00
|
|
|
{
|
2011-01-24 11:36:56 -05:00
|
|
|
COGL_NOTE (CLIPPING, "Flushed empty clip stack");
|
|
|
|
|
2010-11-02 10:28:12 -04:00
|
|
|
ctx->current_clip_stack_uses_stencil = FALSE;
|
2011-07-06 16:51:00 -04:00
|
|
|
GE (ctx, glDisable (GL_SCISSOR_TEST));
|
2010-05-06 09:15:04 -04:00
|
|
|
return;
|
|
|
|
}
|
2008-06-23 10:57:36 -04:00
|
|
|
|
2010-04-22 09:33:47 -04:00
|
|
|
/* Calculate the scissor rect first so that if we eventually have to
|
|
|
|
clear the stencil buffer then the clear will be clipped to the
|
|
|
|
intersection of all of the bounding boxes. This saves having to
|
|
|
|
clear the whole stencil buffer */
|
2011-01-12 14:13:45 -05:00
|
|
|
_cogl_clip_stack_get_bounds (stack,
|
|
|
|
&scissor_x0, &scissor_y0,
|
|
|
|
&scissor_x1, &scissor_y1);
|
2010-04-22 09:33:47 -04:00
|
|
|
|
|
|
|
/* Enable scissoring as soon as possible */
|
|
|
|
if (scissor_x0 >= scissor_x1 || scissor_y0 >= scissor_y1)
|
|
|
|
scissor_x0 = scissor_y0 = scissor_x1 = scissor_y1 = scissor_y_start = 0;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* We store the entry coordinates in Cogl coordinate space
|
|
|
|
* but OpenGL requires the window origin to be the bottom
|
|
|
|
* left so we may need to convert the incoming coordinates.
|
|
|
|
*
|
|
|
|
* NB: Cogl forces all offscreen rendering to be done upside
|
|
|
|
* down so in this case no conversion is needed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (cogl_is_offscreen (framebuffer))
|
|
|
|
scissor_y_start = scissor_y0;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
int framebuffer_height =
|
2011-03-01 18:12:18 -05:00
|
|
|
cogl_framebuffer_get_height (framebuffer);
|
2010-04-22 09:33:47 -04:00
|
|
|
|
|
|
|
scissor_y_start = framebuffer_height - scissor_y1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-01-24 11:36:56 -05:00
|
|
|
COGL_NOTE (CLIPPING, "Flushing scissor to (%i, %i, %i, %i)",
|
|
|
|
scissor_x0, scissor_y0,
|
|
|
|
scissor_x1, scissor_y1);
|
|
|
|
|
2011-07-06 16:51:00 -04:00
|
|
|
GE (ctx, glEnable (GL_SCISSOR_TEST));
|
|
|
|
GE (ctx, glScissor (scissor_x0, scissor_y_start,
|
|
|
|
scissor_x1 - scissor_x0,
|
|
|
|
scissor_y1 - scissor_y0));
|
2010-04-22 09:33:47 -04:00
|
|
|
|
2010-04-14 08:17:26 -04:00
|
|
|
/* Add all of the entries. This will end up adding them in the
|
|
|
|
reverse order that they were specified but as all of the clips
|
|
|
|
are intersecting it should work out the same regardless of the
|
|
|
|
order */
|
2010-11-01 15:52:45 -04:00
|
|
|
for (entry = stack; entry; entry = entry->parent)
|
2008-12-04 08:45:09 -05:00
|
|
|
{
|
2011-10-03 09:39:05 -04:00
|
|
|
switch (entry->type)
|
2008-12-04 08:45:09 -05:00
|
|
|
{
|
2011-10-03 09:39:05 -04:00
|
|
|
case COGL_CLIP_STACK_PATH:
|
|
|
|
{
|
|
|
|
CoglClipStackPath *path_entry = (CoglClipStackPath *) entry;
|
2011-01-24 11:36:56 -05:00
|
|
|
|
2011-10-03 09:39:05 -04:00
|
|
|
COGL_NOTE (CLIPPING, "Adding stencil clip for path");
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2011-10-03 09:39:05 -04:00
|
|
|
add_stencil_clip_path (framebuffer,
|
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
|
|
|
path_entry->matrix_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
path_entry->path,
|
|
|
|
using_stencil_buffer,
|
|
|
|
TRUE);
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2011-10-03 09:39:05 -04:00
|
|
|
using_stencil_buffer = TRUE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case COGL_CLIP_STACK_PRIMITIVE:
|
2008-12-04 08:45:09 -05:00
|
|
|
{
|
2011-10-03 09:39:05 -04:00
|
|
|
CoglClipStackPrimitive *primitive_entry =
|
|
|
|
(CoglClipStackPrimitive *) entry;
|
|
|
|
|
|
|
|
COGL_NOTE (CLIPPING, "Adding stencil clip for primitive");
|
|
|
|
|
|
|
|
add_stencil_clip_primitive (framebuffer,
|
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
|
|
|
primitive_entry->matrix_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
primitive_entry->primitive,
|
|
|
|
primitive_entry->bounds_x1,
|
|
|
|
primitive_entry->bounds_y1,
|
|
|
|
primitive_entry->bounds_x2,
|
|
|
|
primitive_entry->bounds_y2,
|
|
|
|
using_stencil_buffer,
|
|
|
|
TRUE);
|
2010-11-09 07:01:04 -05:00
|
|
|
|
2011-10-03 09:39:05 -04:00
|
|
|
using_stencil_buffer = TRUE;
|
|
|
|
break;
|
2008-12-04 08:45:09 -05:00
|
|
|
}
|
2011-10-03 09:39:05 -04:00
|
|
|
case COGL_CLIP_STACK_RECT:
|
|
|
|
{
|
|
|
|
CoglClipStackRect *rect = (CoglClipStackRect *) entry;
|
|
|
|
|
|
|
|
/* We don't need to do anything extra if the clip for this
|
|
|
|
rectangle was entirely described by its scissor bounds */
|
|
|
|
if (!rect->can_be_scissor)
|
|
|
|
{
|
|
|
|
/* If we support clip planes and we haven't already used
|
|
|
|
them then use that instead */
|
|
|
|
if (has_clip_planes)
|
|
|
|
{
|
|
|
|
COGL_NOTE (CLIPPING,
|
|
|
|
"Adding clip planes clip for rectangle");
|
|
|
|
|
|
|
|
set_clip_planes (framebuffer,
|
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
|
|
|
rect->matrix_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
rect->x0,
|
|
|
|
rect->y0,
|
|
|
|
rect->x1,
|
|
|
|
rect->y1);
|
|
|
|
using_clip_planes = TRUE;
|
|
|
|
/* We can't use clip planes a second time */
|
|
|
|
has_clip_planes = FALSE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
COGL_NOTE (CLIPPING, "Adding stencil clip for rectangle");
|
|
|
|
|
|
|
|
add_stencil_clip_rectangle (framebuffer,
|
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
|
|
|
rect->matrix_entry,
|
2011-10-03 09:39:05 -04:00
|
|
|
rect->x0,
|
|
|
|
rect->y0,
|
|
|
|
rect->x1,
|
|
|
|
rect->y1,
|
|
|
|
!using_stencil_buffer);
|
|
|
|
using_stencil_buffer = TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case COGL_CLIP_STACK_WINDOW_RECT:
|
|
|
|
break;
|
|
|
|
/* We don't need to do anything for window space rectangles because
|
|
|
|
* their functionality is entirely implemented by the entry bounding
|
|
|
|
* box */
|
2008-12-04 08:45:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Enabling clip planes is delayed to now so that they won't affect
|
|
|
|
setting up the stencil buffer */
|
|
|
|
if (using_clip_planes)
|
2009-11-04 14:42:17 -05:00
|
|
|
enable_clip_planes ();
|
2008-12-04 08:45:09 -05:00
|
|
|
|
2010-11-02 10:28:12 -04:00
|
|
|
ctx->current_clip_stack_uses_stencil = using_stencil_buffer;
|
|
|
|
}
|