isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-30 03:50:47 -05:00
Code Issues Packages Projects Releases Wiki Activity
ae3a9eec7c
mutter/cogl/cogl-journal.c

1377 lines
48 KiB
C
Raw Normal View History

[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2007,2008,2009 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
Remove mentions of the FSF address Since using addresses that might change is something that finally the FSF acknowledge as a plausible scenario (after changing address twice), the license blurb in the source files should use the URI for getting the license in case the library did not come with it. Not that URIs cannot possibly change, but at least it's easier to set up a redirection at the same place. As a side note: this commit closes the oldes bug in Clutter's bug report tool. http://bugzilla.openedhand.com/show_bug.cgi?id=521
2010-03-01 07:56:10 -05:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
*
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "cogl.h"
cogl: don't include cogl-debug.h in cogl.h or install cogl-debug.h is an internal header so it shouldn't have been included by cogl.h and the header shouldn't be installed either.
2010-07-25 16:36:41 -04:00
#include "cogl-debug.h"
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#include "cogl-internal.h"
#include "cogl-context.h"
#include "cogl-journal-private.h"
#include "cogl-texture-private.h"
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
#include "cogl-pipeline-private.h"
#include "cogl-pipeline-opengl-private.h"
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#include "cogl-vertex-buffer-private.h"
cogl: deprecate cogl_draw_buffer API and replace with a cogl_framebuffer API cogl_push_draw_buffer, cogl_set_draw_buffer and cogl_pop_draw_buffer are now deprecated and new code should use the new cogl_framebuffer_* API instead. Code that previously did: cogl_push_draw_buffer (); cogl_set_draw_buffer (COGL_OFFSCREEN_BUFFER, buffer); /* draw */ cogl_pop_draw_buffer (); should now be re-written as: cogl_push_framebuffer (buffer); /* draw */ cogl_pop_framebuffer (); As can be seen from the example above the rename has been used as an opportunity to remove the redundant target argument from cogl_set_draw_buffer; it now only takes one call to redirect to an offscreen buffer, and finally the term framebuffer may be a bit more familiar to anyone coming from an OpenGL background.
2009-11-26 14:06:35 -05:00
#include "cogl-framebuffer-private.h"
profiling: Adds initial UProf accounting to Cogl This adds gives Cogl a dedicated UProf context which will be linked together with Clutter's context during clutter_init_real(). Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad You can explicitly ask for a report of Cogl statistics by exporting COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's the statisitcs will also be shown in the automatic Clutter reports.
2009-07-03 11:22:35 -04:00
#include "cogl-profile.h"
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
#include "cogl-vertex-attribute-private.h"
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#include <string.h>
#include <gmodule.h>
#include <math.h>
/* XXX NB:
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
* The data logged in logged_vertices is formatted as follows:
*
* Per entry:
* 4 RGBA GLubytes for the color
* 2 floats for the top left position
* 2 * n_layers floats for the top left texture coordinates
* 2 floats for the bottom right position
* 2 * n_layers floats for the bottom right texture coordinates
*/
#define GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS(N_LAYERS) \
(N_LAYERS * 2 + 2)
/* XXX NB:
* Once in the vertex array, the journal's vertex data is arranged as follows:
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* 4 vertices per quad:
* 2 or 3 GLfloats per position (3 when doing software transforms)
* 4 RGBA GLubytes,
* 2 GLfloats per tex coord * n_layers
*
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* Where n_layers corresponds to the number of pipeline layers enabled
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
*
* To avoid frequent changes in the stride of our vertex data we always pad
* n_layers to be >= 2
*
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
* There will be four vertices per quad in the vertex array
*
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* When we are transforming quads in software we need to also track the z
* coordinate of transformed vertices.
*
* So for a given number of layers this gets the stride in 32bit words:
*/
#define SW_TRANSFORM (!(cogl_debug_flags & \
COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
#define POS_STRIDE (SW_TRANSFORM ? 3 : 2) /* number of 32bit words */
#define N_POS_COMPONENTS POS_STRIDE
#define COLOR_STRIDE 1 /* number of 32bit words */
#define TEX_STRIDE 2 /* number of 32bit words */
#define MIN_LAYER_PADING 2
#define GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS(N_LAYERS) \
(POS_STRIDE + COLOR_STRIDE + \
TEX_STRIDE * (N_LAYERS < MIN_LAYER_PADING ? MIN_LAYER_PADING : N_LAYERS))
cogl-journal: Attempt to clip manually to avoid breaking up batches Before flushing the journal there is now a separate iteration that will try to determine if the matrix of the clip stack and the matrix of the rectangle in each entry are on the same plane. If they are it can completely avoid the clip stack and instead manually modify the vertex and texture coordinates to implement the clip. The has the advantage that it won't break up batching if a single clipped rectangle is used in a scene. The software clip is only used if there is no user program and no texture matrices. There is a threshold to the size of the batch where it is assumed that it is worth the cost to break up a batch and program the GPU to do the clipping. Currently this is set to 8 although this figure is plucked out of thin air. To check whether the two matrices are on the same plane it tries to determine if one of the matrices is just a simple translation of the other. In the process of this it also works out what the translation would be. These values can be used to translate the clip rectangle into the coordinate space of the rectangle to be logged. Then we can do the clip directly in the rectangle's coordinate space.
2010-11-09 14:18:37 -05:00
/* If a batch is longer than this threshold then we'll assume it's not
worth doing software clipping and it's cheaper to program the GPU
to do the clip */
#define COGL_JOURNAL_HARDWARE_CLIP_THRESHOLD 8
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
typedef struct _CoglJournalFlushState
{
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglVertexArray *vertex_array;
GArray *attributes;
int current_attribute;
gsize stride;
size_t array_offset;
GLuint current_vertex;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#ifndef HAVE_COGL_GL
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglIndices *indices;
gsize indices_type_size;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#endif
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglMatrixStack *modelview_stack;
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
CoglMatrixStack *projection_stack;
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *source;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
} CoglJournalFlushState;
typedef void (*CoglJournalBatchCallback) (CoglJournalEntry *start,
int n_entries,
void *data);
typedef gboolean (*CoglJournalBatchTest) (CoglJournalEntry *entry0,
CoglJournalEntry *entry1);
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
static void
_cogl_journal_dump_logged_quad (guint8 *data, int n_layers)
{
gsize stride = GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS (n_layers);
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
g_print ("n_layers = %d; rgba=0x%02X%02X%02X%02X\n",
n_layers, data[0], data[1], data[2], data[3]);
data += 4;
for (i = 0; i < 2; i++)
{
float *v = (float *)data + (i * stride);
int j;
g_print ("v%d: x = %f, y = %f", i, v[0], v[1]);
for (j = 0; j < n_layers; j++)
{
float *t = v + 2 + TEX_STRIDE * j;
g_print (", tx%d = %f, ty%d = %f", j, t[0], j, t[1]);
}
g_print ("\n");
}
}
static void
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_cogl_journal_dump_quad_vertices (guint8 *data, int n_layers)
{
cogl: improves header and coding style consistency We've had complaints that our Cogl code/headers are a bit "special" so this is a first pass at tidying things up by giving them some consistency. These changes are all consistent with how new code in Cogl is being written, but the style isn't consistently applied across all code yet. There are two parts to this patch; but since each one required a large amount of effort to maintain tidy indenting it made sense to combine the changes to reduce the time spent re indenting the same lines. The first change is to use a consistent style for declaring function prototypes in headers. Cogl headers now consistently use this style for prototypes: return_type cogl_function_name (CoglType arg0, CoglType arg1); Not everyone likes this style, but it seems that most of the currently active Cogl developers agree on it. The second change is to constrain the use of redundant glib data types in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all been replaced with int, unsigned int, float, long, unsigned long and char respectively. When talking about pixel data; use of guchar has been replaced with guint8, otherwise unsigned char can be used. The glib types that we continue to use for portability are gboolean, gint{8,16,32,64}, guint{8,16,32,64} and gsize. The general intention is that Cogl should look palatable to the widest range of C programmers including those outside the Gnome community so - especially for the public API - we want to minimize the number of foreign looking typedefs.
2010-02-09 20:57:32 -05:00
gsize stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (n_layers);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
g_print ("n_layers = %d; stride = %d; pos stride = %d; color stride = %d; "
"tex stride = %d; stride in bytes = %d\n",
n_layers, (int)stride, POS_STRIDE, COLOR_STRIDE,
TEX_STRIDE, (int)stride * 4);
for (i = 0; i < 4; i++)
{
float *v = (float *)data + (i * stride);
guint8 *c = data + (POS_STRIDE * 4) + (i * stride * 4);
int j;
cogl debug: hint that all debugging paths are G_UNLIKELY Most Cogl debugging code conditions are marked as G_UNLIKELY with the intention of having the CPU branch prediction always assume the path is disabled so having debugging support in release binaries has negligible overhead. This patch simply fixes a few cases where we weren't using G_UNLIKELY.
2010-02-17 12:53:28 -05:00
if (G_UNLIKELY (cogl_debug_flags &
COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
g_print ("v%d: x = %f, y = %f, rgba=0x%02X%02X%02X%02X",
i, v[0], v[1], c[0], c[1], c[2], c[3]);
else
g_print ("v%d: x = %f, y = %f, z = %f, rgba=0x%02X%02X%02X%02X",
i, v[0], v[1], v[2], c[0], c[1], c[2], c[3]);
for (j = 0; j < n_layers; j++)
{
float *t = v + POS_STRIDE + COLOR_STRIDE + TEX_STRIDE * j;
g_print (", tx%d = %f, ty%d = %f", j, t[0], j, t[1]);
}
g_print ("\n");
}
}
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
static void
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_cogl_journal_dump_quad_batch (guint8 *data, int n_layers, int n_quads)
{
cogl: improves header and coding style consistency We've had complaints that our Cogl code/headers are a bit "special" so this is a first pass at tidying things up by giving them some consistency. These changes are all consistent with how new code in Cogl is being written, but the style isn't consistently applied across all code yet. There are two parts to this patch; but since each one required a large amount of effort to maintain tidy indenting it made sense to combine the changes to reduce the time spent re indenting the same lines. The first change is to use a consistent style for declaring function prototypes in headers. Cogl headers now consistently use this style for prototypes: return_type cogl_function_name (CoglType arg0, CoglType arg1); Not everyone likes this style, but it seems that most of the currently active Cogl developers agree on it. The second change is to constrain the use of redundant glib data types in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all been replaced with int, unsigned int, float, long, unsigned long and char respectively. When talking about pixel data; use of guchar has been replaced with guint8, otherwise unsigned char can be used. The glib types that we continue to use for portability are gboolean, gint{8,16,32,64}, guint{8,16,32,64} and gsize. The general intention is that Cogl should look palatable to the widest range of C programmers including those outside the Gnome community so - especially for the public API - we want to minimize the number of foreign looking typedefs.
2010-02-09 20:57:32 -05:00
gsize byte_stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (n_layers) * 4;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
int i;
g_print ("_cogl_journal_dump_quad_batch: n_layers = %d, n_quads = %d\n",
n_layers, n_quads);
for (i = 0; i < n_quads; i++)
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
_cogl_journal_dump_quad_vertices (data + byte_stride * 2 * i, n_layers);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
static void
batch_and_call (CoglJournalEntry *entries,
int n_entries,
CoglJournalBatchTest can_batch_callback,
CoglJournalBatchCallback batch_callback,
void *data)
{
int i;
int batch_len = 1;
CoglJournalEntry *batch_start = entries;
Delay default stage creation The default stage creation should be delayed as much as possible, ideally at the end of the init() process.
2009-12-03 12:13:44 -05:00
if (n_entries < 1)
return;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
for (i = 1; i < n_entries; i++)
{
CoglJournalEntry *entry0 = &entries[i - 1];
CoglJournalEntry *entry1 = entry0 + 1;
if (can_batch_callback (entry0, entry1))
{
batch_len++;
continue;
}
batch_callback (batch_start, batch_len, data);
batch_start = entry1;
batch_len = 1;
}
/* The last batch... */
batch_callback (batch_start, batch_len, data);
}
static void
_cogl_journal_flush_modelview_and_entries (CoglJournalEntry *batch_start,
int batch_len,
void *data)
{
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglJournalFlushState *state = data;
CoglVertexAttribute **attributes;
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
COGL_STATIC_TIMER (time_flush_modelview_and_entries,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
"flush: pipeline+entries", /* parent */
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
"flush: modelview+entries",
"The time spent flushing modelview + entries",
0 /* no application private data */);
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
COGL_TIMER_START (_cogl_uprof_context, time_flush_modelview_and_entries);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
g_print ("BATCHING: modelview batch len = %d\n", batch_len);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
[current-matrix] Adds texture matrix stacks + removes GL matrix API usage This relates back to an earlier commitment to stop using the OpenGL matrix API which is considered deprecated. (ref 54159f5a1d029db) The new texture matrix stacks are hung from a list of (internal only) CoglTextureUnit structures which the CoglMaterial code internally references via _cogl_get_texure_unit (). So we would be left with only the cogl-matrix-stack code being responsible for glMatrixMode, glLoadMatrix and glLoadIdentity this commit updates the journal code so it now uses the matrix-stack API instead of GL directly.
2009-09-28 21:58:27 -04:00
{
_cogl_matrix_stack_set (state->modelview_stack,
&batch_start->model_view);
_cogl_matrix_stack_flush_to_gl (state->modelview_stack,
COGL_MATRIX_MODELVIEW);
}
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
attributes = (CoglVertexAttribute **)state->attributes->data;
cogl_push_source (state->source);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#ifdef HAVE_COGL_GL
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
/* XXX: it's rather evil that we sneak in the GL_QUADS enum here... */
_cogl_draw_vertex_attributes_array (GL_QUADS,
state->current_vertex, batch_len * 4,
attributes);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#else /* HAVE_COGL_GL */
if (batch_len > 1)
{
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
_cogl_draw_indexed_vertex_attributes_array (COGL_VERTICES_MODE_TRIANGLES,
state->current_vertex * 6 / 4,
batch_len * 6,
state->indices,
attributes);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
else
{
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
_cogl_draw_vertex_attributes_array (COGL_VERTICES_MODE_TRIANGLE_FAN,
state->current_vertex, 4,
attributes);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
#endif
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
/* DEBUGGING CODE XXX: This path will cause all rectangles to be
* drawn with a coloured outline. Each batch will be rendered with
* the same color. This may e.g. help with debugging texture slicing
* issues, visually seeing what is batched and debugging blending
* issues, plus it looks quite cool.
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
*/
cogl debug: hint that all debugging paths are G_UNLIKELY Most Cogl debugging code conditions are marked as G_UNLIKELY with the intention of having the CPU branch prediction always assume the path is disabled so having debugging support in release binaries has negligible overhead. This patch simply fixes a few cases where we weren't using G_UNLIKELY.
2010-02-17 12:53:28 -05:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_RECTANGLES))
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
{
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
static CoglPipeline *outline = NULL;
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
guint8 color_intensity;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
int i;
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglVertexAttribute *loop_attributes[2];
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
_COGL_GET_CONTEXT (ctxt, NO_RETVAL);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
if (outline == NULL)
outline = cogl_pipeline_new ();
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
/* The least significant three bits represent the three
components so that the order of colours goes red, green,
yellow, blue, magenta, cyan. Black and white are skipped. The
next two bits give four scales of intensity for those colours
in the order 0xff, 0xcc, 0x99, and 0x66. This gives a total
of 24 colours. If there are more than 24 batches on the stage
then it will wrap around */
color_intensity = 0xff - 0x33 * (ctxt->journal_rectangles_color >> 3);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
cogl_pipeline_set_color4ub (outline,
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
(ctxt->journal_rectangles_color & 1) ?
color_intensity : 0,
(ctxt->journal_rectangles_color & 2) ?
color_intensity : 0,
(ctxt->journal_rectangles_color & 4) ?
color_intensity : 0,
0xff);
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
cogl_set_source (outline);
loop_attributes[0] = attributes[0]; /* we just want the position */
loop_attributes[1] = NULL;
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
for (i = 0; i < batch_len; i++)
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
_cogl_draw_vertex_attributes_array (COGL_VERTICES_MODE_LINE_LOOP,
4 * i + state->current_vertex, 4,
loop_attributes);
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
/* Go to the next color */
do
ctxt->journal_rectangles_color = ((ctxt->journal_rectangles_color + 1) &
((1 << 5) - 1));
/* We don't want to use black or white */
while ((ctxt->journal_rectangles_color & 0x07) == 0
|| (ctxt->journal_rectangles_color & 0x07) == 0x07);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
state->current_vertex += (4 * batch_len);
cogl_pop_source ();
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
COGL_TIMER_STOP (_cogl_uprof_context, time_flush_modelview_and_entries);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
static gboolean
compare_entry_modelviews (CoglJournalEntry *entry0,
CoglJournalEntry *entry1)
{
/* Batch together quads with the same model view matrix */
/* FIXME: this is nasty, there are much nicer ways to track this
* (at the add_quad_vertices level) without resorting to a memcmp!
*
* E.g. If the cogl-current-matrix code maintained an "age" for
* the modelview matrix we could simply check in add_quad_vertices
* if the age has increased, and if so record the change as a
* boolean in the journal.
*/
if (memcmp (&entry0->model_view, &entry1->model_view,
sizeof (GLfloat) * 16) == 0)
return TRUE;
else
return FALSE;
}
/* At this point we have a run of quads that we know have compatible
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* pipelines, but they may not all have the same modelview matrix */
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
static void
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
_cogl_journal_flush_pipeline_and_entries (CoglJournalEntry *batch_start,
cogl: improves header and coding style consistency We've had complaints that our Cogl code/headers are a bit "special" so this is a first pass at tidying things up by giving them some consistency. These changes are all consistent with how new code in Cogl is being written, but the style isn't consistently applied across all code yet. There are two parts to this patch; but since each one required a large amount of effort to maintain tidy indenting it made sense to combine the changes to reduce the time spent re indenting the same lines. The first change is to use a consistent style for declaring function prototypes in headers. Cogl headers now consistently use this style for prototypes: return_type cogl_function_name (CoglType arg0, CoglType arg1); Not everyone likes this style, but it seems that most of the currently active Cogl developers agree on it. The second change is to constrain the use of redundant glib data types in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all been replaced with int, unsigned int, float, long, unsigned long and char respectively. When talking about pixel data; use of guchar has been replaced with guint8, otherwise unsigned char can be used. The glib types that we continue to use for portability are gboolean, gint{8,16,32,64}, guint{8,16,32,64} and gsize. The general intention is that Cogl should look palatable to the widest range of C programmers including those outside the Gnome community so - especially for the public API - we want to minimize the number of foreign looking typedefs.
2010-02-09 20:57:32 -05:00
int batch_len,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
void *data)
{
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglJournalFlushState *state = data;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
COGL_STATIC_TIMER (time_flush_pipeline_entries,
"flush: texcoords+pipeline+entries", /* parent */
"flush: pipeline+entries",
"The time spent flushing pipeline + entries",
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
0 /* no application private data */);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
COGL_TIMER_START (_cogl_uprof_context, time_flush_pipeline_entries);
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
g_print ("BATCHING: pipeline batch len = %d\n", batch_len);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
state->source = batch_start->pipeline;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/* If we haven't transformed the quads in software then we need to also break
* up batches according to changes in the modelview matrix... */
cogl debug: hint that all debugging paths are G_UNLIKELY Most Cogl debugging code conditions are marked as G_UNLIKELY with the intention of having the CPU branch prediction always assume the path is disabled so having debugging support in release binaries has negligible overhead. This patch simply fixes a few cases where we weren't using G_UNLIKELY.
2010-02-17 12:53:28 -05:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
{
batch_and_call (batch_start,
batch_len,
compare_entry_modelviews,
_cogl_journal_flush_modelview_and_entries,
data);
}
else
_cogl_journal_flush_modelview_and_entries (batch_start, batch_len, data);
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
COGL_TIMER_STOP (_cogl_uprof_context, time_flush_pipeline_entries);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
static gboolean
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
compare_entry_pipelines (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
{
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
/* batch rectangles using compatible pipelines */
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
/* XXX: _cogl_pipeline_equal may give false negatives since it avoids
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* deep comparisons as an optimization. It aims to compare enough so
* that we that we are able to batch the 90% common cases, but may not
* look at less common differences. */
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
if (_cogl_pipeline_equal (entry0->pipeline,
entry1->pipeline,
CoglMaterial: Implements sparse materials design This is a complete overhaul of the data structures used to manage CoglMaterial state. We have these requirements that were aiming to meet: (Note: the references to "renderlists" correspond to the effort to support scenegraph level shuffling of Clutter actor primitives so we can minimize GPU state changes) Sparse State: We wanted a design that allows sparse descriptions of state so it scales well as we make CoglMaterial responsible for more and more state. It needs to scale well in terms of memory usage and the cost of operations we need to apply to materials such as comparing, copying and flushing their state. I.e. we would rather have these things scale by the number of real changes a material represents not by how much overall state CoglMaterial becomes responsible for. Cheap Copies: As we add support for renderlists in Clutter we will need to be able to get an immutable handle for a given material's current state so that we can retain a record of a primitive with its associated material without worrying that changes to the original material will invalidate that record. No more flush override options: We want to get rid of the flush overrides mechanism we currently use to deal with texture fallbacks, wrap mode changes and to handle the use of highlevel CoglTextures that need to be resolved into lowlevel textures before flushing the material state. The flush options structure has been expanding in size and the structure is logged with every journal entry so it is not an approach that scales well at all. It also makes flushing material state that much more complex. Weak Materials: Again for renderlists we need a way to create materials derived from other materials but without the strict requirement that modifications to the original material wont affect the derived ("weak") material. The only requirement is that its possible to later check if the original material has been changed. A summary of the new design: A CoglMaterial now basically represents a diff against its parent. Each material has a single parent and a mask of state that it changes. Each group of state (such as the blending state) has an "authority" which is found by walking up from a given material through its ancestors checking the difference mask until a match for that group is found. There is only one root node to the graph of all materials, which is the default material first created when Cogl is being initialized. All the groups of state are divided into two types, such that infrequently changed state belongs in a separate "BigState" structure that is only allocated and attached to a material when necessary. CoglMaterialLayers are another sparse structure. Like CoglMaterials they represent a diff against their parent and all the layers are part of another graph with the "default_layer_0" layer being the root node that Cogl creates during initialization. Copying a material is now basically just a case of slice allocating a CoglMaterial, setting the parent to be the source being copied and zeroing the mask of changes. Flush overrides should now be handled by simply relying on the cheapness of copying a material and making changes to it. (This will be done in a follow on commit) Weak material support will be added in a follow on commit.
2010-04-08 07:21:04 -04:00
TRUE))
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
return TRUE;
else
return FALSE;
}
/* Since the stride may not reflect the number of texture layers in use
* (due to padding) we deal with texture coordinate offsets separately
* from vertex and color offsets... */
static void
_cogl_journal_flush_texcoord_vbo_offsets_and_entries (
CoglJournalEntry *batch_start,
cogl: improves header and coding style consistency We've had complaints that our Cogl code/headers are a bit "special" so this is a first pass at tidying things up by giving them some consistency. These changes are all consistent with how new code in Cogl is being written, but the style isn't consistently applied across all code yet. There are two parts to this patch; but since each one required a large amount of effort to maintain tidy indenting it made sense to combine the changes to reduce the time spent re indenting the same lines. The first change is to use a consistent style for declaring function prototypes in headers. Cogl headers now consistently use this style for prototypes: return_type cogl_function_name (CoglType arg0, CoglType arg1); Not everyone likes this style, but it seems that most of the currently active Cogl developers agree on it. The second change is to constrain the use of redundant glib data types in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all been replaced with int, unsigned int, float, long, unsigned long and char respectively. When talking about pixel data; use of guchar has been replaced with guint8, otherwise unsigned char can be used. The glib types that we continue to use for portability are gboolean, gint{8,16,32,64}, guint{8,16,32,64} and gsize. The general intention is that Cogl should look palatable to the widest range of C programmers including those outside the Gnome community so - especially for the public API - we want to minimize the number of foreign looking typedefs.
2010-02-09 20:57:32 -05:00
int batch_len,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
void *data)
{
CoglJournalFlushState *state = data;
int i;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
COGL_STATIC_TIMER (time_flush_texcoord_pipeline_entries,
"flush: vbo+texcoords+pipeline+entries", /* parent */
"flush: texcoords+pipeline+entries",
"The time spent flushing texcoord offsets + pipeline "
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
"+ entries",
0 /* no application private data */);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
COGL_TIMER_START (_cogl_uprof_context, time_flush_texcoord_pipeline_entries);
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
/* NB: attributes 0 and 1 are position and color */
for (i = 2; i < state->attributes->len; i++)
cogl_object_unref (g_array_index (state->attributes,
CoglVertexAttribute *, i));
g_array_set_size (state->attributes, batch_start->n_layers + 2);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
for (i = 0; i < batch_start->n_layers; i++)
{
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglVertexAttribute **attribute_entry =
&g_array_index (state->attributes, CoglVertexAttribute *, i + 2);
const char *names[] = {
"cogl_tex_coord0_in",
"cogl_tex_coord1_in",
"cogl_tex_coord2_in",
"cogl_tex_coord3_in",
"cogl_tex_coord4_in",
"cogl_tex_coord5_in",
"cogl_tex_coord6_in",
"cogl_tex_coord7_in"
};
char *name;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/* XXX NB:
* Our journal's vertex data is arranged as follows:
* 4 vertices per quad:
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
* 2 or 3 floats per position (3 when doing software transforms)
* 4 RGBA bytes,
* 2 floats per tex coord * n_layers
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* (though n_layers may be padded; see definition of
* GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS for details)
*/
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
name = i < 8 ? (char *)names[i] :
g_strdup_printf ("cogl_tex_coord%d_in", i);
/* XXX: it may be worth having some form of static initializer for
* attributes... */
*attribute_entry =
cogl_vertex_attribute_new (state->vertex_array,
name,
state->stride,
state->array_offset +
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
(POS_STRIDE + COLOR_STRIDE) * 4 +
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
TEX_STRIDE * 4 * i,
2,
COGL_VERTEX_ATTRIBUTE_TYPE_FLOAT);
cogl-vertex-buffer: Don't disable layers with no texture coords It should be quite acceptable to use a texture without defining any texture coords. For example a shader may be in use that is doing texture lookups without referencing the texture coordinates. Also it should be possible to replace the vertex colors using a texture layer without a texture but with a constant layer color. enable_state_for_drawing_buffer no longer sets any disabled layers in the overrides. Instead of counting the number of units with texture coordinates it now keeps them in a mask. This means there can now be gaps in the list of enabled texture coordinate arrays. To cope with this, the Cogl context now also stores a mask to track the enabled arrays. Instead of code manually iterating each enabled array to disable them, there is now an internal function called _cogl_disable_texcoord_arrays which disables a given mask. I think this could also fix potential bugs when a vertex buffer has gaps in the texture coordinate attributes that it provides. For example if the vertex buffer only had texture coordinates for layer 2 then the disabling code would not disable the coordinates for layers 0 and 1 even though they are not used. This could cause a crash if the previous data for those arrays is no longer valid. http://bugzilla.openedhand.com/show_bug.cgi?id=2132
2010-05-19 19:16:49 -04:00
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
if (i >= 8)
g_free (name);
}
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
batch_and_call (batch_start,
batch_len,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
compare_entry_pipelines,
_cogl_journal_flush_pipeline_and_entries,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
data);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
COGL_TIMER_STOP (_cogl_uprof_context, time_flush_texcoord_pipeline_entries);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
static gboolean
compare_entry_n_layers (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
{
if (entry0->n_layers == entry1->n_layers)
return TRUE;
else
return FALSE;
}
/* At this point we know the stride has changed from the previous batch
* of journal entries */
static void
_cogl_journal_flush_vbo_offsets_and_entries (CoglJournalEntry *batch_start,
cogl: improves header and coding style consistency We've had complaints that our Cogl code/headers are a bit "special" so this is a first pass at tidying things up by giving them some consistency. These changes are all consistent with how new code in Cogl is being written, but the style isn't consistently applied across all code yet. There are two parts to this patch; but since each one required a large amount of effort to maintain tidy indenting it made sense to combine the changes to reduce the time spent re indenting the same lines. The first change is to use a consistent style for declaring function prototypes in headers. Cogl headers now consistently use this style for prototypes: return_type cogl_function_name (CoglType arg0, CoglType arg1); Not everyone likes this style, but it seems that most of the currently active Cogl developers agree on it. The second change is to constrain the use of redundant glib data types in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all been replaced with int, unsigned int, float, long, unsigned long and char respectively. When talking about pixel data; use of guchar has been replaced with guint8, otherwise unsigned char can be used. The glib types that we continue to use for portability are gboolean, gint{8,16,32,64}, guint{8,16,32,64} and gsize. The general intention is that Cogl should look palatable to the widest range of C programmers including those outside the Gnome community so - especially for the public API - we want to minimize the number of foreign looking typedefs.
2010-02-09 20:57:32 -05:00
int batch_len,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
void *data)
{
CoglJournalFlushState *state = data;
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
gsize stride;
int i;
CoglVertexAttribute **attribute_entry;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
COGL_STATIC_TIMER (time_flush_vbo_texcoord_pipeline_entries,
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
"flush: clip+vbo+texcoords+pipeline+entries", /* parent */
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
"flush: vbo+texcoords+pipeline+entries",
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
"The time spent flushing vbo + texcoord offsets + "
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
"pipeline + entries",
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
0 /* no application private data */);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
COGL_TIMER_START (_cogl_uprof_context,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
time_flush_vbo_texcoord_pipeline_entries);
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
g_print ("BATCHING: vbo offset batch len = %d\n", batch_len);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/* XXX NB:
* Our journal's vertex data is arranged as follows:
* 4 vertices per quad:
* 2 or 3 GLfloats per position (3 when doing software transforms)
* 4 RGBA GLubytes,
* 2 GLfloats per tex coord * n_layers
* (though n_layers may be padded; see definition of
* GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS for details)
*/
stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (batch_start->n_layers);
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
stride *= sizeof (float);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
state->stride = stride;
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
for (i = 0; i < state->attributes->len; i++)
cogl_object_unref (g_array_index (state->attributes,
CoglVertexAttribute *, i));
g_array_set_size (state->attributes, 2);
attribute_entry =
&g_array_index (state->attributes, CoglVertexAttribute *, 0);
*attribute_entry =
cogl_vertex_attribute_new (state->vertex_array,
"cogl_position_in",
stride,
state->array_offset,
N_POS_COMPONENTS,
COGL_VERTEX_ATTRIBUTE_TYPE_FLOAT);
attribute_entry =
&g_array_index (state->attributes, CoglVertexAttribute *, 1);
*attribute_entry =
cogl_vertex_attribute_new (state->vertex_array,
"cogl_color_in",
stride,
state->array_offset + (POS_STRIDE * 4),
4,
COGL_VERTEX_ATTRIBUTE_TYPE_UNSIGNED_BYTE);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#ifndef HAVE_COGL_GL
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
state->indices = cogl_get_rectangle_indices (batch_len);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#endif
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
/* We only create new VertexAttributes when the stride within the
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* VertexArray changes. (due to a change in the number of pipeline layers)
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* While the stride remains constant we walk forward through the above
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
* VertexArray using a vertex offset passed to cogl_draw_vertex_attributes
*/
state->current_vertex = 0;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl debug: hint that all debugging paths are G_UNLIKELY Most Cogl debugging code conditions are marked as G_UNLIKELY with the intention of having the CPU branch prediction always assume the path is disabled so having debugging support in release binaries has negligible overhead. This patch simply fixes a few cases where we weren't using G_UNLIKELY.
2010-02-17 12:53:28 -05:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_JOURNAL))
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
{
guint8 *verts;
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
/* Mapping a buffer for read is probably a really bad thing to
do but this will only happen during debugging so it probably
doesn't matter */
verts = (cogl_buffer_map (COGL_BUFFER (state->vertex_array),
COGL_BUFFER_ACCESS_READ, 0) +
state->array_offset);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_cogl_journal_dump_quad_batch (verts,
batch_start->n_layers,
batch_len);
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
cogl_buffer_unmap (COGL_BUFFER (state->vertex_array));
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
batch_and_call (batch_start,
batch_len,
compare_entry_n_layers,
_cogl_journal_flush_texcoord_vbo_offsets_and_entries,
data);
/* progress forward through the VBO containing all our vertices */
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
state->array_offset += (stride * 4 * batch_len);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_JOURNAL))
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
g_print ("new vbo offset = %lu\n", (unsigned long)state->array_offset);
journal: provide more detailed uprof instrumentation This adds more timing around key stages of the journal flushing process.
2010-07-26 10:21:18 -04:00
COGL_TIMER_STOP (_cogl_uprof_context,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
time_flush_vbo_texcoord_pipeline_entries);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
static gboolean
compare_entry_strides (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
{
/* Currently the only thing that affects the stride for our vertex arrays
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* is the number of pipeline layers. We need to update our VBO offsets
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* whenever the stride changes. */
/* TODO: We should be padding the n_layers == 1 case as if it were
* n_layers == 2 so we can reduce the need to split batches. */
if (entry0->n_layers == entry1->n_layers ||
(entry0->n_layers <= MIN_LAYER_PADING &&
entry1->n_layers <= MIN_LAYER_PADING))
return TRUE;
else
return FALSE;
}
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
/* At this point we know the batch has a unique clip stack */
static void
_cogl_journal_flush_clip_stacks_and_entries (CoglJournalEntry *batch_start,
int batch_len,
void *data)
{
CoglJournalFlushState *state = data;
COGL_STATIC_TIMER (time_flush_clip_stack_pipeline_entries,
"Journal Flush", /* parent */
"flush: clip+vbo+texcoords+pipeline+entries",
"The time spent flushing clip + vbo + texcoord offsets + "
"pipeline + entries",
0 /* no application private data */);
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
COGL_TIMER_START (_cogl_uprof_context,
time_flush_clip_stack_pipeline_entries);
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
g_print ("BATCHING: clip stack batch len = %d\n", batch_len);
_cogl_clip_stack_flush (batch_start->clip_stack);
_cogl_matrix_stack_push (state->modelview_stack);
/* If we have transformed all our quads at log time then we ensure
* no further model transform is applied by loading the identity
* matrix here. We need to do this after flushing the clip stack
* because the clip stack flushing code can modify the matrix */
if (G_LIKELY (!(cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM)))
{
_cogl_matrix_stack_load_identity (state->modelview_stack);
_cogl_matrix_stack_flush_to_gl (state->modelview_stack,
COGL_MATRIX_MODELVIEW);
}
/* Setting up the clip state can sometimes also flush the projection
matrix so we should flush it again. This will be a no-op if the
clip code didn't modify the projection */
_cogl_matrix_stack_flush_to_gl (state->projection_stack,
COGL_MATRIX_PROJECTION);
batch_and_call (batch_start,
batch_len,
compare_entry_strides,
_cogl_journal_flush_vbo_offsets_and_entries, /* callback */
data);
_cogl_matrix_stack_pop (state->modelview_stack);
COGL_TIMER_STOP (_cogl_uprof_context,
time_flush_clip_stack_pipeline_entries);
}
cogl-journal: Attempt to clip manually to avoid breaking up batches Before flushing the journal there is now a separate iteration that will try to determine if the matrix of the clip stack and the matrix of the rectangle in each entry are on the same plane. If they are it can completely avoid the clip stack and instead manually modify the vertex and texture coordinates to implement the clip. The has the advantage that it won't break up batching if a single clipped rectangle is used in a scene. The software clip is only used if there is no user program and no texture matrices. There is a threshold to the size of the batch where it is assumed that it is worth the cost to break up a batch and program the GPU to do the clipping. Currently this is set to 8 although this figure is plucked out of thin air. To check whether the two matrices are on the same plane it tries to determine if one of the matrices is just a simple translation of the other. In the process of this it also works out what the translation would be. These values can be used to translate the clip rectangle into the coordinate space of the rectangle to be logged. Then we can do the clip directly in the rectangle's coordinate space.
2010-11-09 14:18:37 -05:00
static gboolean
calculate_translation (const CoglMatrix *a,
const CoglMatrix *b,
float *tx_p,
float *ty_p)
{
float tx, ty;
int x, y;
/* Assuming we had the original matrix in this form:
*
* [ a₁₁, a₁₂, a₁₃, a₁₄ ]
* [ a₂₁, a₂₂, a₂₃, a₂₄ ]
* a = [ a₃₁, a₃₂, a₃₃, a₃₄ ]
* [ a₄₁, a₄₂, a₄₃, a₄₄ ]
*
* then a translation of that matrix would be a multiplication by a
* matrix of this form:
*
* [ 1, 0, 0, x ]
* [ 0, 1, 0, y ]
* t = [ 0, 0, 1, 0 ]
* [ 0, 0, 0, 1 ]
*
* That would give us a matrix of this form.
*
* [ a₁₁, a₁₂, a₁₃, a₁₁ x + a₁₂ y + a₁₄ ]
* [ a₂₁, a₂₂, a₂₃, a₂₁ x + a₂₂ y + a₂₄ ]
* b = a ⋅ t = [ a₃₁, a₃₂, a₃₃, a₃₁ x + a₃₂ y + a₃₄ ]
* [ a₄₁, a₄₂, a₄₃, a₄₁ x + a₄₂ y + a₄₄ ]
*
* We can use the two equations from the top left of the matrix to
* work out the x and y translation given the two matrices:
*
* b₁₄ = a₁₁x + a₁₂y + a₁₄
* b₂₄ = a₂₁x + a₂₂y + a₂₄
*
* Rearranging gives us:
*
* a₁₂ b₂₄ - a₂₄ a₁₂
* ----------------- + a₁₄ - b₁₄
* a₂₂
* x = ---------------------------------
* a₁₂ a₂₁
* ------- - a₁₁
* a₂₂
*
* b₂₄ - a₂₁x - a₂₄
* y = ----------------
* a₂₂
*
* Once we've worked out what x and y would be if this was a valid
* translation then we can simply verify that the rest of the matrix
* matches up.
*/
/* The leftmost 3x4 part of the matrix shouldn't change by a
translation so we can just compare it directly */
for (y = 0; y < 4; y++)
for (x = 0; x < 3; x++)
if ((&a->xx)[x * 4 + y] != (&b->xx)[x * 4 + y])
return FALSE;
tx = (((a->xy * b->yw - a->yw * a->xy) / a->yy + a->xw - b->xw) /
((a->xy * a->yx) / a->yy - a->xx));
ty = (b->yw - a->yx * tx - a->yw) / a->yy;
#define APPROX_EQUAL(a, b) (fabsf ((a) - (b)) < 1e-6f)
/* Check whether the 4th column of the matrices match up to the
calculation */
if (!APPROX_EQUAL (b->xw, a->xx * tx + a->xy * ty + a->xw) ||
!APPROX_EQUAL (b->yw, a->yx * tx + a->yy * ty + a->yw) ||
!APPROX_EQUAL (b->zw, a->zx * tx + a->zy * ty + a->zw) ||
!APPROX_EQUAL (b->ww, a->wx * tx + a->wy * ty + a->ww))
return FALSE;
#undef APPROX_EQUAL
*tx_p = tx;
*ty_p = ty;
return TRUE;
}
typedef struct
{
float x_1, y_1;
float x_2, y_2;
} ClipBounds;
static void
check_software_clip_for_batch (CoglJournalEntry *batch_start,
int batch_len,
CoglJournalFlushState *state)
{
CoglClipStack *clip_stack, *clip_entry;
int entry_num;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* This tries to find cases where the entry is logged with a clip
but it would be faster to modify the vertex and texture
coordinates rather than flush the clip so that it can batch
better */
/* If the batch is reasonably long then it's worthwhile programming
the GPU to do the clip */
if (batch_len >= COGL_JOURNAL_HARDWARE_CLIP_THRESHOLD)
return;
clip_stack = batch_start->clip_stack;
if (clip_stack == NULL)
return;
/* Verify that all of the clip stack entries are a simple rectangle
clip */
for (clip_entry = clip_stack; clip_entry; clip_entry = clip_entry->parent)
if (clip_entry->type != COGL_CLIP_STACK_RECT)
return;
/* This scratch buffer is used to store the translation for each
entry in the journal. We store it in a separate buffer because
it's expensive to calculate but at this point we still don't know
whether we can clip all of the entries so we don't want to do the
rest of the dependant calculations until we're sure we can. */
if (ctx->journal_clip_bounds == NULL)
ctx->journal_clip_bounds = g_array_new (FALSE, FALSE, sizeof (ClipBounds));
g_array_set_size (ctx->journal_clip_bounds, batch_len);
for (entry_num = 0; entry_num < batch_len; entry_num++)
{
CoglJournalEntry *journal_entry = batch_start + entry_num;
CoglPipeline *pipeline = journal_entry->pipeline;
ClipBounds *clip_bounds = &g_array_index (ctx->journal_clip_bounds,
ClipBounds, entry_num);
int layer_num;
clip_bounds->x_1 = -G_MAXFLOAT;
clip_bounds->y_1 = -G_MAXFLOAT;
clip_bounds->x_2 = G_MAXFLOAT;
clip_bounds->y_2 = G_MAXFLOAT;
/* Check the pipeline is usable. We can short-cut here for
entries using the same pipeline as the previous entry */
if (entry_num == 0 || pipeline != batch_start[entry_num - 1].pipeline)
{
/* If the pipeline has a user program then we can't reliably modify
the texture coordinates */
if (cogl_pipeline_get_user_program (pipeline))
return;
/* If any of the pipeline layers have a texture matrix then we can't
reliably modify the texture coordinates */
for (layer_num = cogl_pipeline_get_n_layers (pipeline) - 1;
layer_num >= 0;
layer_num--)
if (_cogl_pipeline_layer_has_user_matrix (pipeline, layer_num))
return;
}
/* Now we need to verify that each clip entry's matrix is just a
translation of the journal entry's modelview matrix. We can
also work out the bounds of the clip in modelview space using
this translation */
for (clip_entry = clip_stack; clip_entry; clip_entry = clip_entry->parent)
{
float rect_x1, rect_y1, rect_x2, rect_y2;
CoglClipStackRect *clip_rect;
float tx, ty;
clip_rect = (CoglClipStackRect *) clip_entry;
if (!calculate_translation (&clip_rect->matrix,
&journal_entry->model_view,
&tx, &ty))
return;
if (clip_rect->x0 < clip_rect->x1)
{
rect_x1 = clip_rect->x0;
rect_x2 = clip_rect->x1;
}
else
{
rect_x1 = clip_rect->x1;
rect_x2 = clip_rect->x0;
}
if (clip_rect->y0 < clip_rect->y1)
{
rect_y1 = clip_rect->y0;
rect_y2 = clip_rect->y1;
}
else
{
rect_y1 = clip_rect->y1;
rect_y2 = clip_rect->y0;
}
clip_bounds->x_1 = MAX (clip_bounds->x_1, rect_x1 - tx);
clip_bounds->y_1 = MAX (clip_bounds->y_1, rect_y1 - ty);
clip_bounds->x_2 = MIN (clip_bounds->x_2, rect_x2 - tx);
clip_bounds->y_2 = MIN (clip_bounds->y_2, rect_y2 - ty);
}
}
/* If we make it here then we know we can software clip the entire batch */
for (entry_num = 0; entry_num < batch_len; entry_num++)
{
CoglJournalEntry *journal_entry = batch_start + entry_num;
float *verts = &g_array_index (ctx->logged_vertices, float,
journal_entry->array_offset + 1);
ClipBounds *clip_bounds = &g_array_index (ctx->journal_clip_bounds,
ClipBounds, entry_num);
size_t stride =
GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS (journal_entry->n_layers);
float rx1, ry1, rx2, ry2;
float vx1, vy1, vx2, vy2;
int layer_num;
/* Remove the clip on the entry */
_cogl_clip_stack_unref (journal_entry->clip_stack);
journal_entry->clip_stack = NULL;
vx1 = verts[0];
vy1 = verts[1];
vx2 = verts[stride];
vy2 = verts[stride + 1];
if (vx1 < vx2)
{
rx1 = vx1;
rx2 = vx2;
}
else
{
rx1 = vx2;
rx2 = vx1;
}
if (vy1 < vy2)
{
ry1 = vy1;
ry2 = vy2;
}
else
{
ry1 = vy2;
ry2 = vy1;
}
rx1 = CLAMP (rx1, clip_bounds->x_1, clip_bounds->x_2);
ry1 = CLAMP (ry1, clip_bounds->y_1, clip_bounds->y_2);
rx2 = CLAMP (rx2, clip_bounds->x_1, clip_bounds->x_2);
ry2 = CLAMP (ry2, clip_bounds->y_1, clip_bounds->y_2);
/* Check if the rectangle intersects the clip at all */
if (rx1 == rx2 || ry1 == ry2)
/* Will set all of the vertex data to 0 in the hope that this
will create a degenerate rectangle and the GL driver will
be able to clip it quickly */
memset (verts, 0, sizeof (float) * stride * 2);
else
{
if (vx1 > vx2)
{
float t = rx1;
rx1 = rx2;
rx2 = t;
}
if (vy1 > vy2)
{
float t = ry1;
ry1 = ry2;
ry2 = t;
}
verts[0] = rx1;
verts[1] = ry1;
verts[stride] = rx2;
verts[stride + 1] = ry2;
/* Convert the rectangle coordinates to a fraction of the original
rectangle */
rx1 = (rx1 - vx1) / (vx2 - vx1);
ry1 = (ry1 - vy1) / (vy2 - vy1);
rx2 = (rx2 - vx1) / (vx2 - vx1);
ry2 = (ry2 - vy1) / (vy2 - vy1);
for (layer_num = 0; layer_num < journal_entry->n_layers; layer_num++)
{
float *t = verts + 2 + 2 * layer_num;
float tx1 = t[0], ty1 = t[1];
float tx2 = t[stride], ty2 = t[stride + 1];
t[0] = rx1 * (tx2 - tx1) + tx1;
t[1] = ry1 * (ty2 - ty1) + ty1;
t[stride] = rx2 * (tx2 - tx1) + tx1;
t[stride + 1] = ry2 * (ty2 - ty1) + ty1;
}
}
}
return;
}
static void
_cogl_journal_check_software_clip (CoglJournalEntry *batch_start,
int batch_len,
void *data)
{
CoglJournalFlushState *state = data;
COGL_STATIC_TIMER (time_check_software_clip,
"Journal Flush", /* parent */
"flush: check software clip",
"Time spent checking for software clip",
0 /* no application private data */);
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
COGL_TIMER_START (_cogl_uprof_context,
time_check_software_clip);
check_software_clip_for_batch (batch_start, batch_len, state);
COGL_TIMER_STOP (_cogl_uprof_context,
time_check_software_clip);
}
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
static gboolean
compare_entry_clip_stacks (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
{
return entry0->clip_stack == entry1->clip_stack;
}
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
static CoglVertexArray *
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
upload_vertices (const CoglJournalEntry *entries,
int n_entries,
size_t needed_vbo_len,
GArray *vertices)
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
{
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
CoglVertexArray *array;
CoglBuffer *buffer;
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
const float *vin;
float *vout;
int entry_num;
int i;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
g_assert (needed_vbo_len);
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
array = cogl_vertex_array_new (needed_vbo_len * 4, NULL);
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
buffer = COGL_BUFFER (array);
cogl_buffer_set_update_hint (buffer, COGL_BUFFER_UPDATE_HINT_STATIC);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
vout = cogl_buffer_map (buffer, COGL_BUFFER_ACCESS_WRITE,
COGL_BUFFER_MAP_HINT_DISCARD);
vin = &g_array_index (vertices, float, 0);
/* Expand the number of vertices from 2 to 4 while uploading */
for (entry_num = 0; entry_num < n_entries; entry_num++)
{
const CoglJournalEntry *entry = entries + entry_num;
size_t vb_stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (entry->n_layers);
size_t array_stride =
GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS (entry->n_layers);
/* Copy the color to all four of the vertices */
for (i = 0; i < 4; i++)
memcpy (vout + vb_stride * i + POS_STRIDE, vin, 4);
vin++;
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
{
vout[vb_stride * 0] = vin[0];
vout[vb_stride * 0 + 1] = vin[1];
vout[vb_stride * 1] = vin[0];
vout[vb_stride * 1 + 1] = vin[array_stride + 1];
vout[vb_stride * 2] = vin[array_stride];
vout[vb_stride * 2 + 1] = vin[array_stride + 1];
vout[vb_stride * 3] = vin[array_stride];
vout[vb_stride * 3 + 1] = vin[1];
}
else
{
float v[8];
v[0] = vin[0];
v[1] = vin[1];
v[2] = vin[0];
v[3] = vin[array_stride + 1];
v[4] = vin[array_stride];
v[5] = vin[array_stride + 1];
v[6] = vin[array_stride];
v[7] = vin[1];
cogl_matrix_transform_points (&entry->model_view,
2, /* n_components */
sizeof (float) * 2, /* stride_in */
v, /* points_in */
/* strideout */
vb_stride * sizeof (float),
vout, /* points_out */
4 /* n_points */);
}
for (i = 0; i < entry->n_layers; i++)
{
const float *tin = vin + 2;
float *tout = vout + POS_STRIDE + COLOR_STRIDE;
tout[vb_stride * 0 + i * 2] = tin[i * 2];
tout[vb_stride * 0 + 1 + i * 2] = tin[i * 2 + 1];
tout[vb_stride * 1 + i * 2] = tin[i * 2];
tout[vb_stride * 1 + 1 + i * 2] = tin[array_stride + i * 2 + 1];
tout[vb_stride * 2 + i * 2] = tin[array_stride + i * 2];
tout[vb_stride * 2 + 1 + i * 2] = tin[array_stride + i * 2 + 1];
tout[vb_stride * 3 + i * 2] = tin[array_stride + i * 2];
tout[vb_stride * 3 + 1 + i * 2] = tin[i * 2 + 1];
}
vin += array_stride * 2;
vout += vb_stride * 4;
}
cogl_buffer_unmap (buffer);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
return array;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
/* XXX NB: When _cogl_journal_flush() returns all state relating
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* to pipelines, all glEnable flags and current matrix state
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* is undefined.
*/
void
_cogl_journal_flush (void)
{
CoglJournalFlushState state;
int i;
framebuffer: Replace CoglHandle with CoglFramebuffer * One more object converted to stop using CoglHandle re:a8c8cbee513
2010-07-07 09:41:54 -04:00
CoglFramebuffer *framebuffer;
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 09:34:34 -04:00
CoglMatrixStack *modelview_stack;
profiling: Adds initial UProf accounting to Cogl This adds gives Cogl a dedicated UProf context which will be linked together with Clutter's context during clutter_init_real(). Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad You can explicitly ask for a report of Cogl statistics by exporting COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's the statisitcs will also be shown in the automatic Clutter reports.
2009-07-03 11:22:35 -04:00
COGL_STATIC_TIMER (flush_timer,
"Mainloop", /* parent */
"Journal Flush",
"The time spent flushing the Cogl journal",
0 /* no application private data */);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (ctx->journal->len == 0)
return;
profiling: Adds initial UProf accounting to Cogl This adds gives Cogl a dedicated UProf context which will be linked together with Clutter's context during clutter_init_real(). Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad You can explicitly ask for a report of Cogl statistics by exporting COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's the statisitcs will also be shown in the automatic Clutter reports.
2009-07-03 11:22:35 -04:00
COGL_TIMER_START (_cogl_uprof_context, flush_timer);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
g_print ("BATCHING: journal len = %d\n", ctx->journal->len);
journal: port to the vertex_attributes API Instead of using raw OpenGL in the journal we now use the vertex attributes API instead. This is part of an ongoing effort to reduce the number of drawing paths we maintain in Cogl.
2010-10-26 14:22:57 -04:00
state.attributes = ctx->journal_flush_attributes_array;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl: deprecate cogl_draw_buffer API and replace with a cogl_framebuffer API cogl_push_draw_buffer, cogl_set_draw_buffer and cogl_pop_draw_buffer are now deprecated and new code should use the new cogl_framebuffer_* API instead. Code that previously did: cogl_push_draw_buffer (); cogl_set_draw_buffer (COGL_OFFSCREEN_BUFFER, buffer); /* draw */ cogl_pop_draw_buffer (); should now be re-written as: cogl_push_framebuffer (buffer); /* draw */ cogl_pop_framebuffer (); As can be seen from the example above the rename has been used as an opportunity to remove the redundant target argument from cogl_set_draw_buffer; it now only takes one call to redirect to an offscreen buffer, and finally the term framebuffer may be a bit more familiar to anyone coming from an OpenGL background.
2009-11-26 14:06:35 -05:00
framebuffer = _cogl_get_framebuffer ();
modelview_stack = _cogl_framebuffer_get_modelview_stack (framebuffer);
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 09:34:34 -04:00
state.modelview_stack = modelview_stack;
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
state.projection_stack = _cogl_framebuffer_get_projection_stack (framebuffer);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
Add a COGL_DEBUG option to disable software clipping This adds a debug option called disable-software-clipping which causes the journal to always log the clip stack state rather than trying to manually clip rectangles.
2010-11-10 09:02:31 -05:00
if (G_UNLIKELY ((cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_CLIP) == 0))
{
/* We do an initial walk of the journal to analyse the clip stack
batches to see if we can do software clipping. We do this as a
separate walk of the journal because we can modify entries and
this may end up joining together clip stack batches in the next
iteration. */
batch_and_call ((CoglJournalEntry *)ctx->journal->data, /* first entry */
ctx->journal->len, /* max number of entries to consider */
compare_entry_clip_stacks,
_cogl_journal_check_software_clip, /* callback */
&state); /* data */
}
cogl-journal: Attempt to clip manually to avoid breaking up batches Before flushing the journal there is now a separate iteration that will try to determine if the matrix of the clip stack and the matrix of the rectangle in each entry are on the same plane. If they are it can completely avoid the clip stack and instead manually modify the vertex and texture coordinates to implement the clip. The has the advantage that it won't break up batching if a single clipped rectangle is used in a scene. The software clip is only used if there is no user program and no texture matrices. There is a threshold to the size of the batch where it is assumed that it is worth the cost to break up a batch and program the GPU to do the clipping. Currently this is set to 8 although this figure is plucked out of thin air. To check whether the two matrices are on the same plane it tries to determine if one of the matrices is just a simple translation of the other. In the process of this it also works out what the translation would be. These values can be used to translate the clip rectangle into the coordinate space of the rectangle to be logged. Then we can do the clip directly in the rectangle's coordinate space.
2010-11-09 14:18:37 -05:00
/* We upload the vertices after the clip stack pass in case it
modifies the entries */
state.vertex_array = upload_vertices (&g_array_index (ctx->journal,
CoglJournalEntry, 0),
ctx->journal->len,
ctx->journal_needed_vbo_len,
ctx->logged_vertices);
state.array_offset = 0;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/* batch_and_call() batches a list of journal entries according to some
* given criteria and calls a callback once for each determined batch.
*
* The process of flushing the journal is staggered to reduce the amount
* of driver/GPU state changes necessary:
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
* 1) We split the entries according to the clip state.
* 2) We split the entries according to the stride of the vertices:
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* Each time the stride of our vertex data changes we need to call
* gl{Vertex,Color}Pointer to inform GL of new VBO offsets.
* Currently the only thing that affects the stride of our vertex data
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* is the number of pipeline layers.
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
* 3) We split the entries explicitly by the number of pipeline layers:
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* We pad our vertex data when the number of layers is < 2 so that we
* can minimize changes in stride. Each time the number of layers
* changes we need to call glTexCoordPointer to inform GL of new VBO
* offsets.
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
* 4) We then split according to compatible Cogl pipelines:
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* This is where we flush pipeline state
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
* 5) Finally we split according to modelview matrix changes:
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* This is when we finally tell GL to draw something.
* Note: Splitting by modelview changes is skipped when are doing the
* vertex transformation in software at log time.
*/
batch_and_call ((CoglJournalEntry *)ctx->journal->data, /* first entry */
ctx->journal->len, /* max number of entries to consider */
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
compare_entry_clip_stacks,
_cogl_journal_flush_clip_stacks_and_entries, /* callback */
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
&state); /* data */
Free state at the end of a journal flush At the end of flushing the journal, we need to free the vertex attributes and vertex array. http://bugzilla.clutter-project.org/show_bug.cgi?id=2423
2010-11-15 01:32:42 -05:00
for (i = 0; i < state.attributes->len; i++)
cogl_object_unref (g_array_index (state.attributes,
CoglVertexAttribute *, i));
g_array_set_size (state.attributes, 0);
cogl_object_unref (state.vertex_array);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
for (i = 0; i < ctx->journal->len; i++)
{
CoglJournalEntry *entry =
&g_array_index (ctx->journal, CoglJournalEntry, i);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
_cogl_pipeline_journal_unref (entry->pipeline);
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
_cogl_clip_stack_unref (entry->clip_stack);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
g_array_set_size (ctx->journal, 0);
g_array_set_size (ctx->logged_vertices, 0);
profiling: Adds initial UProf accounting to Cogl This adds gives Cogl a dedicated UProf context which will be linked together with Clutter's context during clutter_init_real(). Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad You can explicitly ask for a report of Cogl statistics by exporting COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's the statisitcs will also be shown in the automatic Clutter reports.
2009-07-03 11:22:35 -04:00
COGL_TIMER_STOP (_cogl_uprof_context, flush_timer);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 09:34:34 -04:00
static void
_cogl_journal_init (void)
{
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 09:34:34 -04:00
/* Here we flush anything that we know must remain constant until the
* next the the journal is flushed. Note: This lets up flush things
* that themselves depend on the journal, such as clip state. */
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
/* NB: the journal deals with flushing the modelview stack and clip
state manually */
cogl: deprecate cogl_draw_buffer API and replace with a cogl_framebuffer API cogl_push_draw_buffer, cogl_set_draw_buffer and cogl_pop_draw_buffer are now deprecated and new code should use the new cogl_framebuffer_* API instead. Code that previously did: cogl_push_draw_buffer (); cogl_set_draw_buffer (COGL_OFFSCREEN_BUFFER, buffer); /* draw */ cogl_pop_draw_buffer (); should now be re-written as: cogl_push_framebuffer (buffer); /* draw */ cogl_pop_framebuffer (); As can be seen from the example above the rename has been used as an opportunity to remove the redundant target argument from cogl_set_draw_buffer; it now only takes one call to redirect to an offscreen buffer, and finally the term framebuffer may be a bit more familiar to anyone coming from an OpenGL background.
2009-11-26 14:06:35 -05:00
_cogl_framebuffer_flush_state (_cogl_get_framebuffer (),
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
COGL_FRAMEBUFFER_FLUSH_SKIP_MODELVIEW |
COGL_FRAMEBUFFER_FLUSH_SKIP_CLIP_STATE);
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
ctx->journal_needed_vbo_len = 0;
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 09:34:34 -04:00
}
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
void
cogl_rectangle: avoid redundant copy of geometry All the cogl_rectangle* APIs normalize their input into into an array of _CoglMutiTexturedRect rectangles and pass these on to our work horse; _cogl_rectangles_with_multitexture_coords. The definition of _CoglMutiTexturedRect had 4 separate float members, x_1, y_1, x_2 and y_2 which meant for some common cases we were having to copy out from an array into these members. We are now able to simply point into the users array avoiding a copy which seems desirable when submiting lots of rectangles.
2010-02-11 10:33:01 -05:00
_cogl_journal_log_quad (const float *position,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *pipeline,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
int n_layers,
cogl-pipeline: Use layer overrides as CoglHandles instead of GLuint Since d5634e37 the sliced texture backend now works in terms of CoglTexture2Ds so there's no need to have special casing for overriding the texture of a pipeline layer with a GL handle. Instead we can just use cogl_pipeline_set_layer_texture with the CoglHandle. The special _cogl_pipeline_set_layer_gl_texture_slice function has now been removed and parts of the code for comparing materials have been simplified.
2010-11-11 11:18:25 -05:00
CoglHandle layer0_override_texture,
cogl: Make the callback for foreach_sub_texture_in_region use const The CoglTextureSliceCallback function pointer now takes const pointers for the texture coordinates. This makes it clearer that the callback should not modify the array and therefore the backend can use the same array for both sets of coords.
2009-12-02 12:17:24 -05:00
const float *tex_coords,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
unsigned int tex_coords_len)
{
cogl: improves header and coding style consistency We've had complaints that our Cogl code/headers are a bit "special" so this is a first pass at tidying things up by giving them some consistency. These changes are all consistent with how new code in Cogl is being written, but the style isn't consistently applied across all code yet. There are two parts to this patch; but since each one required a large amount of effort to maintain tidy indenting it made sense to combine the changes to reduce the time spent re indenting the same lines. The first change is to use a consistent style for declaring function prototypes in headers. Cogl headers now consistently use this style for prototypes: return_type cogl_function_name (CoglType arg0, CoglType arg1); Not everyone likes this style, but it seems that most of the currently active Cogl developers agree on it. The second change is to constrain the use of redundant glib data types in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all been replaced with int, unsigned int, float, long, unsigned long and char respectively. When talking about pixel data; use of guchar has been replaced with guint8, otherwise unsigned char can be used. The glib types that we continue to use for portability are gboolean, gint{8,16,32,64}, guint{8,16,32,64} and gsize. The general intention is that Cogl should look palatable to the widest range of C programmers including those outside the Gnome community so - especially for the public API - we want to minimize the number of foreign looking typedefs.
2010-02-09 20:57:32 -05:00
gsize stride;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
int next_vert;
GLfloat *v;
int i;
int next_entry;
guint32 disable_layers;
CoglJournalEntry *entry;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *source;
CoglPipelineFlushOptions flush_options;
profiling: Adds initial UProf accounting to Cogl This adds gives Cogl a dedicated UProf context which will be linked together with Clutter's context during clutter_init_real(). Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad You can explicitly ask for a report of Cogl statistics by exporting COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's the statisitcs will also be shown in the automatic Clutter reports.
2009-07-03 11:22:35 -04:00
COGL_STATIC_TIMER (log_timer,
"Mainloop", /* parent */
"Journal Log",
"The time spent logging in the Cogl journal",
0 /* no application private data */);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
profiling: Adds initial UProf accounting to Cogl This adds gives Cogl a dedicated UProf context which will be linked together with Clutter's context during clutter_init_real(). Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad You can explicitly ask for a report of Cogl statistics by exporting COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's the statisitcs will also be shown in the automatic Clutter reports.
2009-07-03 11:22:35 -04:00
COGL_TIMER_START (_cogl_uprof_context, log_timer);
[draw-buffers] First pass at overhauling Cogl's framebuffer management Cogl's support for offscreen rendering was originally written just to support the clutter_texture_new_from_actor API and due to lack of documentation and several confusing - non orthogonal - side effects of using the API it wasn't really possible to use directly. This commit does a number of things: - It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h} files instead which should be easier to maintain. - internally CoglFbo objects are now called CoglDrawBuffers. A CoglDrawBuffer is an abstract base class that is inherited from to implement CoglOnscreen and CoglOffscreen draw buffers. CoglOffscreen draw buffers will initially be used to support the cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will start to be used internally to represent windows as we aim to migrate some of Clutter's backend code to Cogl. - It makes draw buffer objects the owners of the following state: - viewport - projection matrix stack - modelview matrix stack - clip state (This means when you switch between draw buffers you will automatically be switching to their associated viewport, matrix and clip state) Aside from hopefully making cogl_offscreen_new_to_texture be more useful short term by having simpler and well defined semantics for cogl_set_draw_buffer, as mentioned above this is the first step for a couple of other things: - Its a step toward moving ownership for windows down from Clutter backends into Cogl, by (internally at least) introducing the CoglOnscreen draw buffer. Note: the plan is that cogl_set_draw_buffer will accept on or offscreen draw buffer handles, and the "target" argument will become redundant since we will instead query the type of the given draw buffer handle. - Because we have a common type for on and offscreen framebuffers we can provide a unified API for framebuffer management. Things like: - blitting between buffers - managing ancillary buffers (e.g. attaching depth and stencil buffers) - size requisition - clearing
2009-09-25 09:34:34 -04:00
if (ctx->logged_vertices->len == 0)
_cogl_journal_init ();
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
/* The vertex data is logged into a separate array. The data needs
to be copied into a vertex array before it's given to GL so we
only store two vertices per quad and expand it to four while
uploading. */
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
/* XXX: See definition of GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS for details
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* about how we pack our vertex data */
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
stride = GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS (n_layers);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
next_vert = ctx->logged_vertices->len;
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
g_array_set_size (ctx->logged_vertices, next_vert + 2 * stride + 1);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
v = &g_array_index (ctx->logged_vertices, GLfloat, next_vert);
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
/* We calculate the needed size of the vbo as we go because it
depends on the number of layers in each entry and it's not easy
calculate based on the length of the logged vertices array */
ctx->journal_needed_vbo_len +=
GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (n_layers) * 4;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/* XXX: All the jumping around to fill in this strided buffer doesn't
* seem ideal. */
/* FIXME: This is a hacky optimization, since it will break if we
* change the definition of CoglColor: */
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
_cogl_pipeline_get_colorubv (pipeline, (guint8 *) v);
v++;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
memcpy (v, position, sizeof (float) * 2);
memcpy (v + stride, position + 2, sizeof (float) * 2);
cogl_rectangle: avoid redundant copy of geometry All the cogl_rectangle* APIs normalize their input into into an array of _CoglMutiTexturedRect rectangles and pass these on to our work horse; _cogl_rectangles_with_multitexture_coords. The definition of _CoglMutiTexturedRect had 4 separate float members, x_1, y_1, x_2 and y_2 which meant for some common cases we were having to copy out from an array into these members. We are now able to simply point into the users array avoiding a copy which seems desirable when submiting lots of rectangles.
2010-02-11 10:33:01 -05:00
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
for (i = 0; i < n_layers; i++)
{
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
/* XXX: See definition of GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS
* for details about how we pack our vertex data */
GLfloat *t = v + 2 + i * 2;
memcpy (t, tex_coords + i * 4, sizeof (float) * 2);
memcpy (t + stride, tex_coords + i * 4 + 2, sizeof (float) * 2);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_JOURNAL))
{
g_print ("Logged new quad:\n");
v = &g_array_index (ctx->logged_vertices, GLfloat, next_vert);
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
_cogl_journal_dump_logged_quad ((guint8 *)v, n_layers);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
next_entry = ctx->journal->len;
g_array_set_size (ctx->journal, next_entry + 1);
entry = &g_array_index (ctx->journal, CoglJournalEntry, next_entry);
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
entry->n_layers = n_layers;
cogl-journal: Attempt to clip manually to avoid breaking up batches Before flushing the journal there is now a separate iteration that will try to determine if the matrix of the clip stack and the matrix of the rectangle in each entry are on the same plane. If they are it can completely avoid the clip stack and instead manually modify the vertex and texture coordinates to implement the clip. The has the advantage that it won't break up batching if a single clipped rectangle is used in a scene. The software clip is only used if there is no user program and no texture matrices. There is a threshold to the size of the batch where it is assumed that it is worth the cost to break up a batch and program the GPU to do the clipping. Currently this is set to 8 although this figure is plucked out of thin air. To check whether the two matrices are on the same plane it tries to determine if one of the matrices is just a simple translation of the other. In the process of this it also works out what the translation would be. These values can be used to translate the clip rectangle into the coordinate space of the rectangle to be logged. Then we can do the clip directly in the rectangle's coordinate space.
2010-11-09 14:18:37 -05:00
entry->array_offset = next_vert;
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
source = pipeline;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
material: Adds backend abstraction for fragment processing As part of an effort to improve the architecture of CoglMaterial internally this overhauls how we flush layer state to OpenGL by adding a formal backend abstraction for fragment processing and further formalizing the CoglTextureUnit abstraction. There are three backends: "glsl", "arbfp" and "fixed". The fixed backend uses the OpenGL fixed function APIs to setup the fragment processing, the arbfp backend uses code generation to handle fragment processing using an ARBfp program, and the GLSL backend is currently only there as a formality to handle user programs associated with a material. (i.e. the glsl backend doesn't yet support code generation) The GLSL backend has highest precedence, then arbfp and finally the fixed. If a backend can't support some particular CoglMaterial feature then it will fallback to the next backend. This adds three new COGL_DEBUG options: * "disable-texturing" as expected should disable all texturing * "disable-arbfp" always make the arbfp backend fallback * "disable-glsl" always make the glsl backend fallback * "show-source" show code generated by the arbfp/glsl backends
2010-04-26 05:01:43 -04:00
if (G_UNLIKELY (ctx->legacy_state_set))
{
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
source = cogl_pipeline_copy (pipeline);
_cogl_pipeline_apply_legacy_state (source);
material: Adds backend abstraction for fragment processing As part of an effort to improve the architecture of CoglMaterial internally this overhauls how we flush layer state to OpenGL by adding a formal backend abstraction for fragment processing and further formalizing the CoglTextureUnit abstraction. There are three backends: "glsl", "arbfp" and "fixed". The fixed backend uses the OpenGL fixed function APIs to setup the fragment processing, the arbfp backend uses code generation to handle fragment processing using an ARBfp program, and the GLSL backend is currently only there as a formality to handle user programs associated with a material. (i.e. the glsl backend doesn't yet support code generation) The GLSL backend has highest precedence, then arbfp and finally the fixed. If a backend can't support some particular CoglMaterial feature then it will fallback to the next backend. This adds three new COGL_DEBUG options: * "disable-texturing" as expected should disable all texturing * "disable-arbfp" always make the arbfp backend fallback * "disable-glsl" always make the glsl backend fallback * "show-source" show code generated by the arbfp/glsl backends
2010-04-26 05:01:43 -04:00
}
material: remove override options from _cogl_material_equal As a follow on to using cogl_material_copy instead of flush options this patch now removes the ability to pass flush options to _cogl_material_equal which is the final reference to the CoglMaterialFlushOptions mechanism.
2010-05-18 18:38:33 -04:00
flush_options.flags = 0;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
if (G_UNLIKELY (cogl_pipeline_get_n_layers (pipeline) != n_layers))
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
{
disable_layers = (1 << n_layers) - 1;
disable_layers = ~disable_layers;
flush_options.disable_layers = disable_layers;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
flush_options.flags |= COGL_PIPELINE_FLUSH_DISABLE_MASK;
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
}
if (G_UNLIKELY (layer0_override_texture))
{
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
flush_options.flags |= COGL_PIPELINE_FLUSH_LAYER0_OVERRIDE;
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
flush_options.layer0_override_texture = layer0_override_texture;
}
if (G_UNLIKELY (flush_options.flags))
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
{
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
/* If we haven't already created a derived pipeline... */
if (source == pipeline)
source = cogl_pipeline_copy (pipeline);
_cogl_pipeline_apply_overrides (source, &flush_options);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
entry->pipeline = _cogl_pipeline_journal_ref (source);
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
entry->clip_stack = _cogl_clip_stack_ref (_cogl_get_clip_stack ());
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
if (G_UNLIKELY (source != pipeline))
cogl: remove _cogl_material_flush_gl_state flush options Since cogl_material_copy should now be cheap to use we can simplify how we handle fallbacks and wrap mode overrides etc by simply copying the original material and making our override changes on the new material. This avoids the need for a sideband state structure that has been growing in size and makes flushing material state more complex. Note the plan is to eventually use weak materials for these override materials and attach these as private data to the original materials so we aren't making so many one-shot materials.
2010-05-18 17:42:49 -04:00
cogl_handle_unref (source);
cogl-journal: Defer expanding the vertices until uploading When logging a quad we now only store the 2 vertices representing the top left and bottom right of the quad. The color is only stored once per entry. Once we come to upload the data we expand the 2 vertices into four and copy the color to each vertex. We do this by mapping the buffer and directly expanding into it. We have to copy the data before we can render it anyway so it doesn't make much sense to expand the vertices before uploading and this way should save some space in the size of the journal. It also makes it slightly easier if we later want to do pre-processing on the journal entries before uploading such as doing software clipping. The modelview matrix is now always copied to the journal entry whereas before it would only be copied if we aren't doing software transform. The journal entry struct always has the space for the modelview matrix so hopefully it's only a small cost to copy the matrix. The transform for the four entries is now done using cogl_matrix_transform_points which may be slightly faster than transforming them each individually with a call to cogl_matrix_transfom.
2010-11-25 16:08:45 -05:00
cogl_get_modelview_matrix (&entry->model_view);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_BATCHING))
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
_cogl_journal_flush ();
profiling: Adds initial UProf accounting to Cogl This adds gives Cogl a dedicated UProf context which will be linked together with Clutter's context during clutter_init_real(). Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad You can explicitly ask for a report of Cogl statistics by exporting COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's the statisitcs will also be shown in the automatic Clutter reports.
2009-07-03 11:22:35 -04:00
COGL_TIMER_STOP (_cogl_uprof_context, log_timer);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
}
Reference in New Issue Copy Permalink