isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-26 18:11:05 -05:00
Code Issues Packages Projects Releases Wiki Activity
cbbf76f280
mutter/cogl/cogl-journal.c

1806 lines
61 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"
cogl: rename cogl-context.h cogl-context-private.h Since we plan to add public cogl_context_* API we need to rename the current cogl-context.h which contains private member details.
2010-11-04 18:25:52 -04:00
#include "cogl-context-private.h"
[cogl-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-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"
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
#include "cogl-attribute-private.h"
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
#include "cogl-point-in-poly-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:
*/
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
#define SW_TRANSFORM (!(COGL_DEBUG_ENABLED \
(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
#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: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
CoglJournal *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
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);
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
static void _cogl_journal_free (CoglJournal *journal);
COGL_OBJECT_DEFINE (Journal, journal);
static void
_cogl_journal_free (CoglJournal *journal)
{
if (journal->entries)
g_array_free (journal->entries, TRUE);
if (journal->vertices)
g_array_free (journal->vertices, TRUE);
g_slice_free (CoglJournal, journal);
}
CoglJournal *
_cogl_journal_new (void)
{
CoglJournal *journal = g_slice_new0 (CoglJournal);
journal->entries = g_array_new (FALSE, FALSE, sizeof (CoglJournalEntry));
journal->vertices = g_array_new (FALSE, FALSE, sizeof (float));
return _cogl_journal_object_new (journal);
}
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: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED
(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;
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
CoglAttribute **attributes;
cogl-journal: Avoid enabling blending if possible The vertex attribute API assumes that if there is a color array enabled then we can't determine if the colors are opaque so we have to enable blending. The journal always uses a color array to avoid switching color state between rectangles. Since the journal switched to using vertex attributes this means we effectively always enable blending from the journal. To fix this there is now a new flag for _cogl_draw_vertex_attributes to specify that the color array is known to only contain opaque colors which causes the draw function not to copy the pipeline. If the pipeline has blending disabled then the journal passes this flag. http://bugzilla.clutter-project.org/show_bug.cgi?id=2481
2010-12-14 09:44:45 -05:00
CoglDrawFlags draw_flags = (COGL_DRAW_SKIP_JOURNAL_FLUSH |
COGL_DRAW_SKIP_PIPELINE_VALIDATION |
cogl-vertex-attribute: Optionally avoid applying the legacy state When an item is added to the journal the current pipeline immediately gets the legacy state applied to it and the modified pipeline is logged instead of the original. However the actual drawing from the journal is done using the vertex attribute API which was also applying the legacy state. This meant that the legacy state used would be a combination of the state set when the journal entry was added as well as the state set when the journal is flushed. To fix this there is now an extra CoglDrawFlag to avoid applying the legacy state when setting up the GL state for the vertex attributes. The journal uses this flag when flushing.
2011-01-10 15:13:41 -05:00
COGL_DRAW_SKIP_FRAMEBUFFER_FLUSH |
COGL_DRAW_SKIP_LEGACY_STATE);
cogl-vertex-attribute: Add flags to _cogl_draw_vertex_attributes_array There is an internal version of cogl_draw_vertex_attributes_array which previously just bypassed the framebuffer flushing, journal flushing and pipeline validation so that it could be used to draw the journal. This patch generalises the function so that it takes a set of flags to specify which parts to flush. The public version of the function now just calls the internal version with the flags set to 0. The '_real' version of the function has now been merged into the internal version of the function because it was only called in one place. This simplifies the code somewhat. The common code which flushed the various state has been moved to a separate function. The indexed versions of the functions have had a similar treatment. http://bugzilla.clutter-project.org/show_bug.cgi?id=2481
2010-12-14 09:24:17 -05: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_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-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
attributes = (CoglAttribute **)state->attributes->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_push_source (state->source);
cogl-journal: Avoid enabling blending if possible The vertex attribute API assumes that if there is a color array enabled then we can't determine if the colors are opaque so we have to enable blending. The journal always uses a color array to avoid switching color state between rectangles. Since the journal switched to using vertex attributes this means we effectively always enable blending from the journal. To fix this there is now a new flag for _cogl_draw_vertex_attributes to specify that the color array is known to only contain opaque colors which causes the draw function not to copy the pipeline. If the pipeline has blending disabled then the journal passes this flag. http://bugzilla.clutter-project.org/show_bug.cgi?id=2481
2010-12-14 09:44:45 -05:00
if (!_cogl_pipeline_get_real_blend_enabled (state->source))
draw_flags |= COGL_DRAW_COLOR_ATTRIBUTE_IS_OPAQUE;
[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: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
_cogl_draw_attributes_array (GL_QUADS,
state->current_vertex, batch_len * 4,
attributes,
draw_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
#else /* HAVE_COGL_GL */
if (batch_len > 1)
{
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
_cogl_draw_indexed_attributes_array (COGL_VERTICES_MODE_TRIANGLES,
state->current_vertex * 6 / 4,
batch_len * 6,
state->indices,
attributes,
draw_flags);
cogl-vertex-attribute: Add flags to _cogl_draw_vertex_attributes_array There is an internal version of cogl_draw_vertex_attributes_array which previously just bypassed the framebuffer flushing, journal flushing and pipeline validation so that it could be used to draw the journal. This patch generalises the function so that it takes a set of flags to specify which parts to flush. The public version of the function now just calls the internal version with the flags set to 0. The '_real' version of the function has now been merged into the internal version of the function because it was only called in one place. This simplifies the code somewhat. The common code which flushed the various state has been moved to a separate function. The indexed versions of the functions have had a similar treatment. http://bugzilla.clutter-project.org/show_bug.cgi?id=2481
2010-12-14 09:24:17 -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
}
else
{
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
_cogl_draw_attributes_array (COGL_VERTICES_MODE_TRIANGLE_FAN,
state->current_vertex, 4,
attributes,
draw_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
}
#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: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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;
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
CoglAttribute *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++)
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
_cogl_draw_attributes_array (COGL_VERTICES_MODE_LINE_LOOP,
4 * i + state->current_vertex, 4,
loop_attributes,
draw_flags);
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-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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
if (_cogl_pipeline_equal (entry0->pipeline,
entry1->pipeline,
pipeline: generalize _cogl_pipeline_equal _cogl_pipeline_equal now accepts a mask of pipeline differences and layer differences to constrain what state will be compared. In addition a set of flags are passed that can tweak the comparison semantics for some state groups. For example when comparing layer textures we sometimes only need to compare the texture target and can ignore the data itself. In updating the code this patch also changes it so all required pipeline authorities are resolved in one step up-front instead of resolving the authority for each state group in turn and repeatedly having to traverse the pipeline's ancestry. This adds two new functions _cogl_pipeline_resolve_authorities and _cogl_pipeline_layer_resolve_authorities to handle resolving a set of authorities.
2010-12-03 06:36:49 -05:00
(COGL_PIPELINE_STATE_ALL &
~COGL_PIPELINE_STATE_COLOR),
COGL_PIPELINE_LAYER_STATE_ALL,
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
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: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
cogl_object_unref (g_array_index (state->attributes, CoglAttribute *, 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
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++)
{
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
CoglAttribute **attribute_entry =
&g_array_index (state->attributes, CoglAttribute *, i + 2);
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
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: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
cogl_attribute_new (state->vertex_array,
name,
state->stride,
state->array_offset +
(POS_STRIDE + COLOR_STRIDE) * 4 +
TEX_STRIDE * 4 * i,
2,
COGL_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;
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
CoglAttribute **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-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
cogl_object_unref (g_array_index (state->attributes, CoglAttribute *, 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
g_array_set_size (state->attributes, 2);
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
attribute_entry = &g_array_index (state->attributes, CoglAttribute *, 0);
*attribute_entry = cogl_attribute_new (state->vertex_array,
"cogl_position_in",
stride,
state->array_offset,
N_POS_COMPONENTS,
COGL_ATTRIBUTE_TYPE_FLOAT);
attribute_entry = &g_array_index (state->attributes, CoglAttribute *, 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
*attribute_entry =
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
cogl_attribute_new (state->vertex_array,
"cogl_color_in",
stride,
state->array_offset + (POS_STRIDE * 4),
4,
COGL_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
cogl: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
/* We only create new Attributes when the stride within the
* VertexArray changes. (due to a change in the number of pipeline
* layers) While the stride remains constant we walk forward through
* the above VertexArray using a vertex offset passed to
* cogl_draw_attributes
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 = 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: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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 */
cogl: Avoid pointer arithmetic on void* pointers Some code was doing pointer arithmetic on the return value from cogl_buffer_map which is void* pointer. This is a GCC extension so we should try to avoid it. This patch adds casts to guint8* where appropriate. Based on a patch by Fan, Chun-wei. http://bugzilla.clutter-project.org/show_bug.cgi?id=2561
2011-02-15 07:43:26 -05:00
verts = ((guint8 *) cogl_buffer_map (COGL_BUFFER (state->vertex_array),
COGL_BUFFER_ACCESS_READ, 0) +
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
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-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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);
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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: 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 */
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_LIKELY (!(COGL_DEBUG_ENABLED (COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))))
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_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;
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
static gboolean
can_software_clip_entry (CoglJournalEntry *journal_entry,
CoglJournalEntry *prev_journal_entry,
CoglClipStack *clip_stack,
ClipBounds *clip_bounds_out)
{
CoglPipeline *pipeline = journal_entry->pipeline;
CoglClipStack *clip_entry;
int layer_num;
clip_bounds_out->x_1 = -G_MAXFLOAT;
clip_bounds_out->y_1 = -G_MAXFLOAT;
clip_bounds_out->x_2 = G_MAXFLOAT;
clip_bounds_out->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 (prev_journal_entry == NULL || pipeline != prev_journal_entry->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 FALSE;
/* 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 FALSE;
}
/* 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 FALSE;
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_out->x_1 = MAX (clip_bounds_out->x_1, rect_x1 - tx);
clip_bounds_out->y_1 = MAX (clip_bounds_out->y_1, rect_y1 - ty);
clip_bounds_out->x_2 = MIN (clip_bounds_out->x_2, rect_x2 - tx);
clip_bounds_out->y_2 = MIN (clip_bounds_out->y_2, rect_y2 - ty);
}
return TRUE;
}
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 void
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
software_clip_entry (CoglJournalEntry *journal_entry,
float *verts,
ClipBounds *clip_bounds)
{
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;
}
}
}
static void
maybe_software_clip_entries (CoglJournalEntry *batch_start,
int batch_len,
CoglJournalFlushState *state)
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
{
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
CoglJournal *journal = state->journal;
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
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;
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
CoglJournalEntry *prev_journal_entry =
entry_num ? batch_start + (entry_num - 1) : NULL;
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
ClipBounds *clip_bounds = &g_array_index (ctx->journal_clip_bounds,
ClipBounds, entry_num);
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
if (!can_software_clip_entry (journal_entry, prev_journal_entry,
clip_stack,
clip_bounds))
return;
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 we make it here then we know we can software clip the entire batch */
cogl-debug: Add a debug option for tracing clipping This adds a COGL_DEBUG=clipping option that reports how the clip is being flushed. This is needed to determine whether the scissor, stencil clip planes or software clipping is being used.
2011-01-24 11:36:56 -05:00
COGL_NOTE (CLIPPING, "Software clipping a batch of length %i", batch_len);
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
for (entry_num = 0; entry_num < batch_len; entry_num++)
{
CoglJournalEntry *journal_entry = batch_start + entry_num;
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
float *verts = &g_array_index (journal->vertices, float,
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
journal_entry->array_offset + 1);
ClipBounds *clip_bounds = &g_array_index (ctx->journal_clip_bounds,
ClipBounds, entry_num);
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
software_clip_entry (journal_entry, verts, clip_bounds);
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
}
return;
}
static void
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
_cogl_journal_maybe_software_clip_entries (CoglJournalEntry *batch_start,
int batch_len,
void *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
{
CoglJournalFlushState *state = data;
COGL_STATIC_TIMER (time_check_software_clip,
"Journal Flush", /* parent */
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
"flush: software clipping",
"Time spent software clipping",
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
0 /* no application private data */);
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
COGL_TIMER_START (_cogl_uprof_context,
time_check_software_clip);
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
maybe_software_clip_entries (batch_start, batch_len, state);
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
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: Fallback to set_data when mapping a buffer to fill it In the journal code and when generating the stroke path the vertices are generated on the fly and stored in a CoglBuffer using cogl_buffer_map. However cogl_buffer_map is allowed to fail but it wasn't checking for a NULL return value. In particular on GLES it will always fail because glMapBuffer is only provided by an extension. This adds a new pair of internal functions called _cogl_buffer_{un,}map_for_fill_or_fallback which wrap cogl_buffer_map. If the map fails then it will instead return a pointer into a GByteArray attached to the context. When the buffer is unmapped the array is copied into the buffer using cogl_buffer_set_data.
2011-01-13 10:35:30 -05:00
vout = _cogl_buffer_map_for_fill_or_fallback (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
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++;
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM)))
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[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: Fallback to set_data when mapping a buffer to fill it In the journal code and when generating the stroke path the vertices are generated on the fly and stored in a CoglBuffer using cogl_buffer_map. However cogl_buffer_map is allowed to fail but it wasn't checking for a NULL return value. In particular on GLES it will always fail because glMapBuffer is only provided by an extension. This adds a new pair of internal functions called _cogl_buffer_{un,}map_for_fill_or_fallback which wrap cogl_buffer_map. If the map fails then it will instead return a pointer into a GByteArray attached to the context. When the buffer is unmapped the array is copied into the buffer using cogl_buffer_set_data.
2011-01-13 10:35:30 -05:00
_cogl_buffer_unmap_for_fill_or_fallback (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
}
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
void
_cogl_journal_discard (CoglJournal *journal)
{
int i;
for (i = 0; i < journal->entries->len; i++)
{
CoglJournalEntry *entry =
&g_array_index (journal->entries, CoglJournalEntry, i);
_cogl_pipeline_journal_unref (entry->pipeline);
_cogl_clip_stack_unref (entry->clip_stack);
}
g_array_set_size (journal->entries, 0);
g_array_set_size (journal->vertices, 0);
journal->needed_vbo_len = 0;
journal->fast_read_pixel_count = 0;
}
/* Note: A return value of FALSE doesn't mean 'no' it means
* 'unknown' */
gboolean
_cogl_journal_all_entries_within_bounds (CoglJournal *journal,
float clip_x0,
float clip_y0,
float clip_x1,
float clip_y1)
{
CoglJournalEntry *entry = (CoglJournalEntry *)journal->entries->data;
CoglClipStack *clip_entry;
CoglClipStack *reference = NULL;
int bounds_x0;
int bounds_y0;
int bounds_x1;
int bounds_y1;
int i;
if (journal->entries->len == 0)
return TRUE;
/* Find the shortest clip_stack ancestry that leaves us in the
* required bounds */
for (clip_entry = entry->clip_stack;
clip_entry;
clip_entry = clip_entry->parent)
{
_cogl_clip_stack_get_bounds (clip_entry,
&bounds_x0, &bounds_y0,
&bounds_x1, &bounds_y1);
if (bounds_x0 >= clip_x0 && bounds_y0 >= clip_y0 &&
bounds_x1 <= clip_x1 && bounds_y1 <= clip_y1)
reference = clip_entry;
else
break;
}
if (!reference)
return FALSE;
/* For the remaining journal entries we will only verify they share
* 'reference' as an ancestor in their clip stack since that's
* enough to know that they would be within the required bounds.
*/
for (i = 1; i < journal->entries->len; i++)
{
gboolean found_reference = FALSE;
entry = &g_array_index (journal->entries, CoglJournalEntry, i);
for (clip_entry = entry->clip_stack;
clip_entry;
clip_entry = clip_entry->parent)
{
if (clip_entry == reference)
{
found_reference = TRUE;
break;
}
}
if (!found_reference)
return FALSE;
}
return 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
/* 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
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
_cogl_journal_flush (CoglJournal *journal,
CoglFramebuffer *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
{
CoglJournalFlushState state;
int i;
[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);
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
if (journal->entries->len == 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
return;
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
/* The entries in this journal may depend on images in other
* framebuffers which may require that we flush the journals
* associated with those framebuffers before we can flush
* this journal... */
_cogl_framebuffer_flush_dependency_journals (framebuffer);
journal: start uprof flush timer after flushing fb deps This avoids us recursively starting the _cogl_journal_flush uprof timer by only starting it after flushing the journals of dependency framebuffers.
2011-01-21 12:38:14 -05:00
/* Note: we start the timer after flushing dependency journals so
* that the timer isn't started recursively. */
COGL_TIMER_START (_cogl_uprof_context, flush_timer);
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
cogl_push_framebuffer (framebuffer);
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (COGL_DEBUG_BATCHING)))
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
g_print ("BATCHING: journal len = %d\n", journal->entries->len);
/* NB: the journal deals with flushing the modelview stack and clip
state manually */
_cogl_framebuffer_flush_state (framebuffer,
cogl-framebuffer: Separate the draw and read buffer The current framebuffer is now internally separated so that there can be a different draw and read buffer. This is required to use the GL_EXT_framebuffer_blit extension. The current draw and read buffers are stored as a pair in a single stack so that pushing the draw and read buffer is done simultaneously with the new _cogl_push_framebuffers internal function. Calling cogl_pop_framebuffer will restore both the draw and read buffer to the previous state. The public cogl_push_framebuffer function is layered on top of the new function so that it just pushes the same buffer for both drawing and reading. When flushing the framebuffer state, the cogl_framebuffer_flush_state function now tackes a pointer to both the draw and the read buffer. Anywhere that was just flushing the state for the current framebuffer with _cogl_get_framebuffer now needs to call both _cogl_get_draw_buffer and _cogl_get_read_buffer.
2011-02-02 09:23:53 -05:00
framebuffer,
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
COGL_FRAMEBUFFER_FLUSH_SKIP_MODELVIEW |
COGL_FRAMEBUFFER_FLUSH_SKIP_CLIP_STATE);
state.journal = 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
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
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
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY ((COGL_DEBUG_ENABLED (COGL_DEBUG_DISABLE_SOFTWARE_CLIP)) == 0))
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
{
/* 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. */
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
batch_and_call ((CoglJournalEntry *)journal->entries->data, /* first entry */
journal->entries->len, /* max number of entries to consider */
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
compare_entry_clip_stacks,
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
_cogl_journal_maybe_software_clip_entries, /* callback */
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
&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 */
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
state.vertex_array = upload_vertices (&g_array_index (journal->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
CoglJournalEntry, 0),
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
journal->entries->len,
journal->needed_vbo_len,
journal->vertices);
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
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.
*/
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
batch_and_call ((CoglJournalEntry *)journal->entries->data, /* first entry */
journal->entries->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: rename CoglVertexAttribute CoglAttribute This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to reduce the verbosity of using the API. Another reason is that CoglVertexArray is going to be renamed CoglAttributeBuffer and we want to help emphasize the relationship between CoglAttributes and CoglAttributeBuffers.
2011-01-20 14:31:53 -05:00
cogl_object_unref (g_array_index (state.attributes, CoglAttribute *, i));
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
g_array_set_size (state.attributes, 0);
cogl_object_unref (state.vertex_array);
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
_cogl_journal_discard (journal);
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
cogl_pop_framebuffer ();
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
}
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
static gboolean
add_framebuffer_deps_cb (CoglPipelineLayer *layer, void *user_data)
[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
{
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
CoglFramebuffer *framebuffer = user_data;
CoglHandle texture = _cogl_pipeline_layer_get_texture_real (layer);
const GList *l;
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
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
if (!texture)
return TRUE;
[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
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
for (l = _cogl_texture_get_associated_framebuffers (texture); l; l = l->next)
_cogl_framebuffer_add_dependency (framebuffer, l->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
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
return TRUE;
[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
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
_cogl_journal_log_quad (CoglJournal *journal,
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;
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
float *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
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;
clip: rename get_clip_stack + add framebuffer_get_stack Instead of having _cogl_get/set_clip stack which reference the global CoglContext this instead makes those into CoglClipState method functions named _cogl_clip_state_get/set_stack that take an explicit pointer to a CoglClipState. This also adds _cogl_framebuffer_get/set_clip_stack convenience functions that avoid having to first get the ClipState from a framebuffer then the stack from that - so we can maintain the convenience of _cogl_get_clip_stack.
2011-01-12 14:30:30 -05:00
CoglClipStack *clip_stack;
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
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);
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
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
next_vert = journal->vertices->len;
g_array_set_size (journal->vertices, next_vert + 2 * stride + 1);
v = &g_array_index (journal->vertices, float, 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 */
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
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
}
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (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
{
g_print ("Logged new quad:\n");
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
v = &g_array_index (journal->vertices, float, 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
}
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
next_entry = journal->entries->len;
g_array_set_size (journal->entries, next_entry + 1);
entry = &g_array_index (journal->entries, CoglJournalEntry, next_entry);
[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
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);
clip: rename get_clip_stack + add framebuffer_get_stack Instead of having _cogl_get/set_clip stack which reference the global CoglContext this instead makes those into CoglClipState method functions named _cogl_clip_state_get/set_stack that take an explicit pointer to a CoglClipState. This also adds _cogl_framebuffer_get/set_clip_stack convenience functions that avoid having to first get the ClipState from a framebuffer then the stack from that - so we can maintain the convenience of _cogl_get_clip_stack.
2011-01-12 14:30:30 -05:00
framebuffer: expose experimental cogl_get_draw_framebuffer This renames the two internal functions _cogl_get_draw/read_buffer as cogl_get_draw_framebuffer and _cogl_get_read_framebuffer. The former is now also exposed as experimental API.
2011-03-10 16:33:31 -05:00
clip_stack = _cogl_framebuffer_get_clip_stack (cogl_get_draw_framebuffer ());
clip: rename get_clip_stack + add framebuffer_get_stack Instead of having _cogl_get/set_clip stack which reference the global CoglContext this instead makes those into CoglClipState method functions named _cogl_clip_state_get/set_stack that take an explicit pointer to a CoglClipState. This also adds _cogl_framebuffer_get/set_clip_stack convenience functions that avoid having to first get the ClipState from a framebuffer then the stack from that - so we can maintain the convenience of _cogl_get_clip_stack.
2011-01-12 14:30:30 -05:00
entry->clip_stack = _cogl_clip_stack_ref (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
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
_cogl_pipeline_foreach_layer_internal (pipeline,
add_framebuffer_deps_cb,
framebuffer: expose experimental cogl_get_draw_framebuffer This renames the two internal functions _cogl_get_draw/read_buffer as cogl_get_draw_framebuffer and _cogl_get_read_framebuffer. The former is now also exposed as experimental API.
2011-03-10 16:33:31 -05:00
cogl_get_draw_framebuffer ());
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
/* XXX: It doesn't feel very nice that in this case we just assume
* that the journal is associated with the current framebuffer. I
* think a journal->framebuffer reference would seem nicer here but
* the reason we don't have that currently is that it would
* introduce a circular reference. */
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (COGL_DEBUG_DISABLE_BATCHING)))
framebuffer: expose experimental cogl_get_draw_framebuffer This renames the two internal functions _cogl_get_draw/read_buffer as cogl_get_draw_framebuffer and _cogl_get_read_framebuffer. The former is now also exposed as experimental API.
2011-03-10 16:33:31 -05:00
_cogl_framebuffer_flush_journal (cogl_get_draw_framebuffer ());
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
}
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
static void
entry_to_screen_polygon (const CoglJournalEntry *entry,
float *vertices,
float *poly)
{
size_t array_stride =
GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS (entry->n_layers);
CoglMatrixStack *projection_stack;
CoglMatrix projection;
int i;
viewport: consistently use floats for viewports OpenGL < 4.0 only supports integer based viewports and internally we have a mixture of code using floats and integers for viewports. This patch switches all viewports throughout clutter and cogl to be represented using floats considering that in the future we may want to take advantage of floating point viewports with modern hardware/drivers.
2011-02-01 11:51:58 -05:00
float viewport[4];
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
poly[0] = vertices[0];
poly[1] = vertices[1];
poly[2] = 0;
poly[3] = 1;
poly[4] = vertices[0];
poly[5] = vertices[array_stride + 1];
poly[6] = 0;
poly[7] = 1;
poly[8] = vertices[array_stride];
poly[9] = vertices[array_stride + 1];
poly[10] = 0;
poly[11] = 1;
poly[12] = vertices[array_stride];
poly[13] = vertices[1];
poly[14] = 0;
poly[15] = 1;
/* TODO: perhaps split the following out into a more generalized
* _cogl_transform_points utility...
*/
cogl_matrix_transform_points (&entry->model_view,
2, /* n_components */
sizeof (float) * 4, /* stride_in */
poly, /* points_in */
/* strideout */
sizeof (float) * 4,
poly, /* points_out */
4 /* n_points */);
projection_stack =
framebuffer: expose experimental cogl_get_draw_framebuffer This renames the two internal functions _cogl_get_draw/read_buffer as cogl_get_draw_framebuffer and _cogl_get_read_framebuffer. The former is now also exposed as experimental API.
2011-03-10 16:33:31 -05:00
_cogl_framebuffer_get_projection_stack (cogl_get_draw_framebuffer ());
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
_cogl_matrix_stack_get (projection_stack, &projection);
cogl_matrix_project_points (&projection,
3, /* n_components */
sizeof (float) * 4, /* stride_in */
poly, /* points_in */
/* strideout */
sizeof (float) * 4,
poly, /* points_out */
4 /* n_points */);
framebuffer: expose experimental cogl_get_draw_framebuffer This renames the two internal functions _cogl_get_draw/read_buffer as cogl_get_draw_framebuffer and _cogl_get_read_framebuffer. The former is now also exposed as experimental API.
2011-03-10 16:33:31 -05:00
_cogl_framebuffer_get_viewport4fv (cogl_get_draw_framebuffer (),
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
viewport);
/* Scale from OpenGL normalized device coordinates (ranging from -1 to 1)
* to Cogl window/framebuffer coordinates (ranging from 0 to buffer-size) with
* (0,0) being top left. */
#define VIEWPORT_TRANSFORM_X(x, vp_origin_x, vp_width) \
( ( ((x) + 1.0) * ((vp_width) / 2.0) ) + (vp_origin_x) )
/* Note: for Y we first flip all coordinates around the X axis while in
* normalized device coodinates */
#define VIEWPORT_TRANSFORM_Y(y, vp_origin_y, vp_height) \
( ( ((-(y)) + 1.0) * ((vp_height) / 2.0) ) + (vp_origin_y) )
/* Scale from normalized device coordinates (in range [-1,1]) to
* window coordinates ranging [0,window-size] ... */
for (i = 0; i < 4; i++)
{
float w = poly[4 * i + 3];
/* Perform perspective division */
poly[4 * i] /= w;
poly[4 * i + 1] /= w;
/* Apply viewport transform */
poly[4 * i] = VIEWPORT_TRANSFORM_X (poly[4 * i],
viewport[0], viewport[2]);
poly[4 * i + 1] = VIEWPORT_TRANSFORM_Y (poly[4 * i + 1],
viewport[1], viewport[3]);
}
#undef VIEWPORT_TRANSFORM_X
#undef VIEWPORT_TRANSFORM_Y
}
static gboolean
try_checking_point_hits_entry_after_clipping (CoglJournalEntry *entry,
float *vertices,
float x,
float y,
gboolean *hit)
{
gboolean can_software_clip = TRUE;
gboolean needs_software_clip = FALSE;
CoglClipStack *clip_entry;
*hit = TRUE;
/* Verify that all of the clip stack entries are simple rectangle
* clips */
for (clip_entry = entry->clip_stack;
clip_entry;
clip_entry = clip_entry->parent)
{
if (x < clip_entry->bounds_x0 ||
x >= clip_entry->bounds_x1 ||
y < clip_entry->bounds_y0 ||
y >= clip_entry->bounds_y1)
{
*hit = FALSE;
return TRUE;
}
if (clip_entry->type == COGL_CLIP_STACK_WINDOW_RECT)
{
/* XXX: technically we could still run the software clip in
* this case because for our purposes we know this clip
* can be ignored now, but [can_]sofware_clip_entry() doesn't
* know this and will bail out. */
can_software_clip = FALSE;
}
else if (clip_entry->type == COGL_CLIP_STACK_RECT)
{
CoglClipStackRect *rect_entry = (CoglClipStackRect *)entry;
if (rect_entry->can_be_scissor == FALSE)
needs_software_clip = TRUE;
/* If can_be_scissor is TRUE then we know it's screen
* aligned and the hit test we did above has determined
* that we are inside this clip. */
}
else
return FALSE;
}
if (needs_software_clip)
{
ClipBounds clip_bounds;
float poly[16];
debug: Adds a COGL_DEBUG=disable-fast-read-pixel option COGL_DEBUG=disable-fast-read-pixel can be used to disable the optimization for reading a single pixel colour back by looking at the geometry in the journal and not involving the GPU. With this disabled we will always flush the journal, rendering to the framebuffer and then use glReadPixels to get the result.
2011-01-20 09:41:51 -05:00
if (!can_software_clip)
return FALSE;
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
if (!can_software_clip_entry (entry, NULL,
entry->clip_stack, &clip_bounds))
return FALSE;
software_clip_entry (entry, vertices, &clip_bounds);
entry_to_screen_polygon (entry, vertices, poly);
util: tune point_in_poly test for polys in screen coords This makes a change to the original point_in_poly algorithm from: http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html The aim was to tune the test so that tests against screen aligned rectangles are more resilient to some in-precision in how we transformed that rectangle into screen coordinates. In particular gnome-shell was finding that for some stage sizes then row 0 of the stage would become a dead zone when going through the software picking fast-path and this was because the y position of screen aligned rectangles could end up as something like 0.00024 and the way the algorithm works it doesn't have any epsilon/fuz factor to consider that in-precision. We've avoided introducing an epsilon factor to the comparisons since we feel there's a risk of changing some semantics in ways that might not be desirable. One of those is that if you transform two polygons which share an edge and test a point close to that edge then this algorithm will currently give a positive result for only one polygon. Another concern is the way this algorithm resolves the corner case where the horizontal ray being cast to count edge crossings may cross directly through a vertex. The solution is based on the "idea of Simulation of Simplicity" and "pretends to shift the ray infinitesimally down so that it either clearly intersects, or clearly doesn't touch". I'm not familiar with the idea myself so I expect a misplaced epsilon is likely to break that aspect of the algorithm. The simple solution this patch applies is to pixel align the polygon vertices which should eradicate most noise due to in-precision. https://bugzilla.gnome.org/show_bug.cgi?id=641197
2011-03-03 18:19:30 -05:00
*hit = _cogl_util_point_in_screen_poly (x, y, poly, sizeof (float) * 4, 4);
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
return TRUE;
}
return TRUE;
}
gboolean
_cogl_journal_try_read_pixel (CoglJournal *journal,
int x,
int y,
CoglPixelFormat format,
guint8 *pixel,
gboolean *found_intersection)
{
int i;
_COGL_GET_CONTEXT (ctx, FALSE);
/* XXX: this number has been plucked out of thin air, but the idea
* is that if so many pixels are being read from the same un-changed
* journal than we expect that it will be more efficient to fail
* here so we end up flushing and rendering the journal so that
* further reads can directly read from the framebuffer. There will
* be a bit more lag to flush the render but if there are going to
* continue being lots of arbitrary single pixel reads they will end
* up faster in the end. */
if (journal->fast_read_pixel_count > 50)
return FALSE;
if (format != COGL_PIXEL_FORMAT_RGBA_8888_PRE &&
format != COGL_PIXEL_FORMAT_RGBA_8888)
return FALSE;
*found_intersection = FALSE;
/* NB: The most recently added journal entry is the last entry, and
* assuming this is a simple scene only comprised of opaque coloured
* rectangles with no special pipelines involved (e.g. enabling
* depth testing) then we can assume painter's algorithm for the
* entries and so our fast read-pixel just needs to walk backwards
* through the journal entries trying to intersect each entry with
* the given point of interest. */
for (i = journal->entries->len - 1; i >= 0; i--)
{
CoglJournalEntry *entry =
&g_array_index (journal->entries, CoglJournalEntry, i);
guint8 *color = (guint8 *)&g_array_index (journal->vertices, float,
entry->array_offset);
float *vertices = (float *)color + 1;
float poly[16];
entry_to_screen_polygon (entry, vertices, poly);
util: tune point_in_poly test for polys in screen coords This makes a change to the original point_in_poly algorithm from: http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html The aim was to tune the test so that tests against screen aligned rectangles are more resilient to some in-precision in how we transformed that rectangle into screen coordinates. In particular gnome-shell was finding that for some stage sizes then row 0 of the stage would become a dead zone when going through the software picking fast-path and this was because the y position of screen aligned rectangles could end up as something like 0.00024 and the way the algorithm works it doesn't have any epsilon/fuz factor to consider that in-precision. We've avoided introducing an epsilon factor to the comparisons since we feel there's a risk of changing some semantics in ways that might not be desirable. One of those is that if you transform two polygons which share an edge and test a point close to that edge then this algorithm will currently give a positive result for only one polygon. Another concern is the way this algorithm resolves the corner case where the horizontal ray being cast to count edge crossings may cross directly through a vertex. The solution is based on the "idea of Simulation of Simplicity" and "pretends to shift the ray infinitesimally down so that it either clearly intersects, or clearly doesn't touch". I'm not familiar with the idea myself so I expect a misplaced epsilon is likely to break that aspect of the algorithm. The simple solution this patch applies is to pixel align the polygon vertices which should eradicate most noise due to in-precision. https://bugzilla.gnome.org/show_bug.cgi?id=641197
2011-03-03 18:19:30 -05:00
if (!_cogl_util_point_in_screen_poly (x, y, poly, sizeof (float) * 4, 4))
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
continue;
/* FIXME: the journal should have a back pointer to the
* associated framebuffer, because it should be possible to read
* a pixel from arbitrary framebuffers without needing to
* internally call _cogl_push/pop_framebuffer.
*/
if (entry->clip_stack)
{
gboolean hit;
if (!try_checking_point_hits_entry_after_clipping (entry, vertices,
x, y, &hit))
return FALSE; /* hit couldn't be determined */
if (!hit)
continue;
}
*found_intersection = TRUE;
/* If we find that the rectangle the point of interest
* intersects has any state more complex than a constant opaque
* color then we bail out. */
if (!_cogl_pipeline_equal (ctx->opaque_color_pipeline, entry->pipeline,
(COGL_PIPELINE_STATE_ALL &
~COGL_PIPELINE_STATE_COLOR),
COGL_PIPELINE_LAYER_STATE_ALL,
0))
return FALSE;
/* we currently only care about cases where the premultiplied or
* unpremultipled colors are equivalent... */
if (color[3] != 0xff)
return FALSE;
pixel[0] = color[0];
pixel[1] = color[1];
pixel[2] = color[2];
pixel[3] = color[3];
goto success;
}
success:
journal->fast_read_pixel_count++;
return TRUE;
}
Reference in New Issue Copy Permalink