isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-09-20 06:25:51 -04:00
Code Issues Packages Projects Releases Wiki Activity
14d8ec7cca
mutter/cogl/cogl-journal.c

1795 lines
62 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
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"
Add internal _cogl_push_source to optionally disable legacy state Some code in Cogl such as when flushing a stencil clip assumes that it can push a temporary simple pipeline to reset to a known state for internal drawing operations. However this breaks down if the application has set any legacy state because that is set globally so it will also get applied to the internal pipeline. _cogl_draw_attributes already had an internal flag to disable applying the legacy state but I think this is quite awkward to use because not all places that push a pipeline draw the attribute buffers directly so it is difficult to pass the flag down through the layers. Conceptually the legacy state is meant to be like a layer on top of the purely pipeline-based state API so I think ideally we should have an internal function to push the source without the applying the legacy state. The legacy state can't be applied as the pipeline is pushed because the global state can be modified even after it is pushed. This patch adds a _cogl_push_source() function which takes an extra boolean flag to mark whether to enable the legacy state. The value of this flag is stored alongside the pipeline in the pipeline stack. Another new internal function called _cogl_get_enable_legacy_state queries whether the top entry in the pipeline stack has legacy state enabled. cogl-primitives and the vertex array drawing code now use this to determine whether to apply the legacy state when drawing. The COGL_DRAW_SKIP_LEGACY_STATE flag is now removed. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-14 07:17:09 -04:00
#include "cogl-private.h"
Move all types/prototypes from cogl.h -> cogl[1]-context.h So we can get to the point where cogl.h is merely an aggregation of header includes for the 1.x api this moves all the function prototypes and type definitions into a cogl-context.h and a new cogl1-context.h. Ideally no code internally should ever need to include cogl.h as it just represents the public facing header for accessing the 1.x api which should only be used by Clutter. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-17 16:46:39 -05:00
#include "cogl1-context.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
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglJournal *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
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
CoglAttributeBuffer *attribute_buffer;
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
GArray *attributes;
int current_attribute;
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
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
size_t stride;
size_t array_offset;
GLuint current_vertex;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglIndices *indices;
size_t indices_type_size;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
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
} CoglJournalFlushState;
typedef void (*CoglJournalBatchCallback) (CoglJournalEntry *start,
int n_entries,
void *data);
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
typedef CoglBool (*CoglJournalBatchTest) (CoglJournalEntry *entry0,
[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
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);
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 13:21:28 -05:00
COGL_OBJECT_INTERNAL_DEFINE (Journal, 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
static void
_cogl_journal_free (CoglJournal *journal)
{
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
int i;
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)
g_array_free (journal->entries, TRUE);
if (journal->vertices)
g_array_free (journal->vertices, TRUE);
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
for (i = 0; i < COGL_JOURNAL_VBO_POOL_SIZE; i++)
if (journal->vbo_pool[i])
cogl_object_unref (journal->vbo_pool[i]);
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_slice_free (CoglJournal, journal);
}
CoglJournal *
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
_cogl_journal_new (CoglFramebuffer *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
{
CoglJournal *journal = g_slice_new0 (CoglJournal);
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
/* The journal keeps a pointer back to the framebuffer because there
is effectively a 1:1 mapping between journals and framebuffers.
However, to avoid a circular reference the journal doesn't take a
reference unless it is non-empty. The framebuffer has a special
unref implementation to ensure that the journal is flushed when
the journal is the only thing keeping it alive */
journal->framebuffer = 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
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
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
_cogl_journal_dump_logged_quad (uint8_t *data, int n_layers)
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
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
size_t stride = GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS (n_layers);
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
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
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
_cogl_journal_dump_quad_vertices (uint8_t *data, int 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
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
size_t 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);
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
uint8_t *c = data + (POS_STRIDE * 4) + (i * stride * 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 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
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
_cogl_journal_dump_quad_batch (uint8_t *data, int n_layers, int n_quads)
[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
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
size_t 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;
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
CoglFramebuffer *framebuffer = state->journal->framebuffer;
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 |
framebuffer: Add cogl_framebuffer draw methods This adds cogl_framebuffer_ apis for drawing attributes and primitives that replace corresponding apis that depend on the default CoglContext. This is part of the on going effort to adapt the Cogl api so it no longer depends on a global context variable. All the new drawing functions also take an explicit pipeline argument since we are also aiming to avoid being a stateful api like Cairo and OpenGL. Being stateless makes it easier for orthogonal components to share access to the GPU. Being stateless should also minimize any impedance miss-match for those wanting to build higher level stateless apis on top of Cogl. Note: none of the legacy, global state options such as cogl_set_depth_test_enabled(), cogl_set_backface_culling_enabled() or cogl_program_use() are supported by these new drawing apis and if set will simply be silently ignored. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 21:59:04 -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)))
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
_cogl_context_set_current_modelview_entry (ctx,
batch_start->modelview_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: 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
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
if (!_cogl_pipeline_get_real_blend_enabled (state->pipeline))
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
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
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
if ((ctx->private_feature_flags & COGL_PRIVATE_FEATURE_QUADS))
[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
{
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* XXX: it's rather evil that we sneak in the GL_QUADS enum here... */
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
_cogl_framebuffer_draw_attributes (framebuffer,
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
state->pipeline,
framebuffer: Add cogl_framebuffer draw methods This adds cogl_framebuffer_ apis for drawing attributes and primitives that replace corresponding apis that depend on the default CoglContext. This is part of the on going effort to adapt the Cogl api so it no longer depends on a global context variable. All the new drawing functions also take an explicit pipeline argument since we are also aiming to avoid being a stateful api like Cairo and OpenGL. Being stateless makes it easier for orthogonal components to share access to the GPU. Being stateless should also minimize any impedance miss-match for those wanting to build higher level stateless apis on top of Cogl. Note: none of the legacy, global state options such as cogl_set_depth_test_enabled(), cogl_set_backface_culling_enabled() or cogl_program_use() are supported by these new drawing apis and if set will simply be silently ignored. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 21:59:04 -05:00
GL_QUADS,
state->current_vertex, batch_len * 4,
attributes,
state->attributes->len,
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
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
else
#endif /* HAVE_COGL_GL */
{
if (batch_len > 1)
{
framebuffer: Add cogl_framebuffer draw methods This adds cogl_framebuffer_ apis for drawing attributes and primitives that replace corresponding apis that depend on the default CoglContext. This is part of the on going effort to adapt the Cogl api so it no longer depends on a global context variable. All the new drawing functions also take an explicit pipeline argument since we are also aiming to avoid being a stateful api like Cairo and OpenGL. Being stateless makes it easier for orthogonal components to share access to the GPU. Being stateless should also minimize any impedance miss-match for those wanting to build higher level stateless apis on top of Cogl. Note: none of the legacy, global state options such as cogl_set_depth_test_enabled(), cogl_set_backface_culling_enabled() or cogl_program_use() are supported by these new drawing apis and if set will simply be silently ignored. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 21:59:04 -05:00
CoglVerticesMode mode = COGL_VERTICES_MODE_TRIANGLES;
int first_vertex = state->current_vertex * 6 / 4;
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
_cogl_framebuffer_draw_indexed_attributes (framebuffer,
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
state->pipeline,
framebuffer: Add cogl_framebuffer draw methods This adds cogl_framebuffer_ apis for drawing attributes and primitives that replace corresponding apis that depend on the default CoglContext. This is part of the on going effort to adapt the Cogl api so it no longer depends on a global context variable. All the new drawing functions also take an explicit pipeline argument since we are also aiming to avoid being a stateful api like Cairo and OpenGL. Being stateless makes it easier for orthogonal components to share access to the GPU. Being stateless should also minimize any impedance miss-match for those wanting to build higher level stateless apis on top of Cogl. Note: none of the legacy, global state options such as cogl_set_depth_test_enabled(), cogl_set_backface_culling_enabled() or cogl_program_use() are supported by these new drawing apis and if set will simply be silently ignored. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 21:59:04 -05:00
mode,
first_vertex,
batch_len * 6,
state->indices,
attributes,
state->attributes->len,
draw_flags);
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
}
else
{
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
_cogl_framebuffer_draw_attributes (framebuffer,
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
state->pipeline,
framebuffer: Add cogl_framebuffer draw methods This adds cogl_framebuffer_ apis for drawing attributes and primitives that replace corresponding apis that depend on the default CoglContext. This is part of the on going effort to adapt the Cogl api so it no longer depends on a global context variable. All the new drawing functions also take an explicit pipeline argument since we are also aiming to avoid being a stateful api like Cairo and OpenGL. Being stateless makes it easier for orthogonal components to share access to the GPU. Being stateless should also minimize any impedance miss-match for those wanting to build higher level stateless apis on top of Cogl. Note: none of the legacy, global state options such as cogl_set_depth_test_enabled(), cogl_set_backface_culling_enabled() or cogl_program_use() are supported by these new drawing apis and if set will simply be silently ignored. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 21:59:04 -05:00
COGL_VERTICES_MODE_TRIANGLE_FAN,
state->current_vertex, 4,
attributes,
state->attributes->len,
draw_flags);
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
}
}
[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
/* 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;
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
uint8_t 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;
Don't pass around NULL terminated CoglAttribute arrays For the first iteration of the CoglAttribute API several of the new functions accepted a pointer to a NULL terminated list of CoglAttribute pointers - probably as a way to reduce the number of arguments required. This style isn't consistent with existing Cogl APIs though and so we now explicitly pass n_attributes arguments and don't require the NULL termination.
2011-03-02 20:02:12 -05:00
CoglAttribute *loop_attributes[1];
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)
Adds a context arg to cogl_pipeline_new() As we move towards Cogl 2.0 we are aiming to remove the need for a default global CoglContext and so everything should be explicitly related to a context somehow. CoglPipelines are top level objects and so this patch adds a context argument to cogl_pipeline_new(). Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-18 11:03:10 -05:00
outline = cogl_pipeline_new (ctxt);
[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
loop_attributes[0] = attributes[0]; /* we just want the position */
cogl: Use the colours of COGL_DEBUG=rectangles to debug batching Instead of assigning a new colour to each quad of a batch, the rectangle debugging code now assigns a new colour to each batch so that it can be used to visually see what is being batched. The colour is stored in a global variable that is reset during cogl_clear. This improves the chances that the same colour will be used for a batch in the next frames to avoid flickering.
2010-01-22 13:14:57 -05:00
for (i = 0; i < batch_len; i++)
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
_cogl_framebuffer_draw_attributes (framebuffer,
framebuffer: Add cogl_framebuffer draw methods This adds cogl_framebuffer_ apis for drawing attributes and primitives that replace corresponding apis that depend on the default CoglContext. This is part of the on going effort to adapt the Cogl api so it no longer depends on a global context variable. All the new drawing functions also take an explicit pipeline argument since we are also aiming to avoid being a stateful api like Cairo and OpenGL. Being stateless makes it easier for orthogonal components to share access to the GPU. Being stateless should also minimize any impedance miss-match for those wanting to build higher level stateless apis on top of Cogl. Note: none of the legacy, global state options such as cogl_set_depth_test_enabled(), cogl_set_backface_culling_enabled() or cogl_program_use() are supported by these new drawing apis and if set will simply be silently ignored. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 21:59:04 -05:00
outline,
COGL_VERTICES_MODE_LINE_LOOP,
4 * i + state->current_vertex, 4,
loop_attributes,
1,
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);
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
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
[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
compare_entry_modelviews (CoglJournalEntry *entry0,
CoglJournalEntry *entry1)
{
/* Batch together quads with the same model view matrix */
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
return entry0->modelview_entry == entry1->modelview_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
}
/* 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
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
state->pipeline = 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
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
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 =
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
cogl_attribute_new (state->attribute_buffer,
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
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
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
[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
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)
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglJournalFlushState *state = data;
CoglContext *ctx = state->journal->framebuffer->context;
size_t stride;
int i;
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
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);
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
*attribute_entry = cogl_attribute_new (state->attribute_buffer,
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_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 =
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
cogl_attribute_new (state->attribute_buffer,
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_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
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
if (!(ctx->private_feature_flags & COGL_PRIVATE_FEATURE_QUADS))
buffer: explicitly relate buffers to a context All CoglBuffer constructors now take an explicit CoglContext constructor. This is part of the on going effort to adapt to Cogl API so it no longer depends on a global, default context. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-06 12:08:58 -05:00
state->indices = cogl_get_rectangle_indices (ctx, 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 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
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
* AttributeBuffer changes. (due to a change in the number of pipeline
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
* layers) While the stride remains constant we walk forward through
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
* the above AttributeBuffer using a vertex offset passed to
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
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
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
uint8_t *verts;
[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
/* 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 */
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
verts = ((uint8_t *)cogl_buffer_map (COGL_BUFFER (state->attribute_buffer),
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
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
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
cogl_buffer_unmap (COGL_BUFFER (state->attribute_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
}
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
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
[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
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;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglFramebuffer *framebuffer = state->journal->framebuffer;
CoglContext *ctx = framebuffer->context;
CoglMatrixStack *projection_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
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_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);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
_cogl_clip_stack_flush (batch_start->clip_stack, framebuffer);
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
framebuffer: Optimize _cogl_framebuffer_flush_state() Previously the cost of _cogl_framebuffer_state_flush() would always scale by the total amount of state tracked by CoglFramebuffer even in cases where we knew up-front that we only wanted to flush a subset of the state or in cases where we requested to flush the same framebuffer multiple times with no changes being made to the framebuffer. We now track a set of state changed flags with each framebuffer and track the current read/draw buffers as part of the CoglContext so that we can quickly bail out when asked to flush the same framebuffer multiple times with no changes. _cogl_framebuffer_flush_state() now takes a mask of the state that we want to flush and the implementation has been redesigned so that the cost of checking what needs to be flushed and flushing those changes now scales by how much state we actually plan to update. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-11-21 10:53:40 -05:00
/* XXX: Because we are manually flushing clip state here we need to
* make sure that the clip state gets updated the next time we flush
* framebuffer state by marking the current framebuffer's clip state
* as changed. */
ctx->current_draw_buffer_changes |= COGL_FRAMEBUFFER_STATE_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
/* 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
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
* because the clip stack flushing code can modify the current
* modelview matrix entry */
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))))
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
_cogl_context_set_current_modelview_entry (ctx, &ctx->identity_entry);
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
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
/* Setting up the clip state can sometimes also update the current
* projection matrix entry so we should update it again. This will have
* no affect if the clip code didn't modify the projection */
projection_stack =
_cogl_framebuffer_get_projection_stack (framebuffer);
_cogl_context_set_current_projection_entry (ctx,
projection_stack->last_entry);
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
batch_and_call (batch_start,
batch_len,
compare_entry_strides,
_cogl_journal_flush_vbo_offsets_and_entries, /* callback */
data);
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
typedef struct
{
float x_1, y_1;
float x_2, y_2;
} ClipBounds;
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
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
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;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
float tx, ty, tz;
CoglMatrixEntry *modelview_entry;
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
clip_rect = (CoglClipStackRect *) clip_entry;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
modelview_entry = journal_entry->modelview_entry;
if (!_cogl_matrix_entry_calculate_translation (clip_rect->matrix_entry,
modelview_entry,
&tx, &ty, &tz))
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 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);
}
cogl-journal: Fix software clipping for non-intersecting rectangles When the clip contains two rectangles which do not intersect it was generating a clip bounds where the bottom-right corner was above or to the left of the top-left corner. This would end up allowing the pixels between the two rectangles instead of clipping everything like it should. To fix this there is now an extra check which detects this situation and just clears the clip bounds to all zeroes in a similar way to what cogl-clip-stack does. https://bugzilla.gnome.org/show_bug.cgi?id=659029 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-14 06:13:30 -04:00
if (clip_bounds_out->x_2 <= clip_bounds_out->x_1 ||
clip_bounds_out->y_2 <= clip_bounds_out->y_1)
memset (clip_bounds_out, 0, sizeof (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
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);
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
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 (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
{
return entry0->clip_stack == entry1->clip_stack;
}
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
/* Gets a new vertex array from the pool. A reference is taken on the
array so it can be treated as if it was just newly allocated */
static CoglAttributeBuffer *
create_attribute_buffer (CoglJournal *journal,
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
size_t n_bytes)
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
{
CoglAttributeBuffer *vbo;
make COGL_FEATURE_VBOS a private feature Cogl provides a consistent public interface regardless of whether the underlying GL driver supports VBOs so it doesn't make much sense to have this feature as part of the public api. We can't break the api by removing the enum but at least we no longer ever set the feature flag. We now have a replacement private feature flag COGL_PRIVATE_FEATURE_VBOS which cogl now checks for internally. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 04:36:46 -04:00
_COGL_GET_CONTEXT (ctx, NULL);
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
/* If CoglBuffers are being emulated with malloc then there's not
really any point in using the pool so we'll just allocate the
buffer directly */
make COGL_FEATURE_VBOS a private feature Cogl provides a consistent public interface regardless of whether the underlying GL driver supports VBOs so it doesn't make much sense to have this feature as part of the public api. We can't break the api by removing the enum but at least we no longer ever set the feature flag. We now have a replacement private feature flag COGL_PRIVATE_FEATURE_VBOS which cogl now checks for internally. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 04:36:46 -04:00
if (!(ctx->private_feature_flags & COGL_PRIVATE_FEATURE_VBOS))
buffer: explicitly relate buffers to a context All CoglBuffer constructors now take an explicit CoglContext constructor. This is part of the on going effort to adapt to Cogl API so it no longer depends on a global, default context. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-06 12:08:58 -05:00
return cogl_attribute_buffer_new (ctx, n_bytes, NULL);
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
vbo = journal->vbo_pool[journal->next_vbo_in_pool];
if (vbo == NULL)
{
buffer: explicitly relate buffers to a context All CoglBuffer constructors now take an explicit CoglContext constructor. This is part of the on going effort to adapt to Cogl API so it no longer depends on a global, default context. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-06 12:08:58 -05:00
vbo = cogl_attribute_buffer_new (ctx, n_bytes, NULL);
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
journal->vbo_pool[journal->next_vbo_in_pool] = vbo;
}
else if (cogl_buffer_get_size (COGL_BUFFER (vbo)) < n_bytes)
{
/* If the buffer is too small then we'll just recreate it */
cogl_object_unref (vbo);
buffer: explicitly relate buffers to a context All CoglBuffer constructors now take an explicit CoglContext constructor. This is part of the on going effort to adapt to Cogl API so it no longer depends on a global, default context. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-06 12:08:58 -05:00
vbo = cogl_attribute_buffer_new (ctx, n_bytes, NULL);
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
journal->vbo_pool[journal->next_vbo_in_pool] = vbo;
}
journal->next_vbo_in_pool = ((journal->next_vbo_in_pool + 1) %
COGL_JOURNAL_VBO_POOL_SIZE);
return cogl_object_ref (vbo);
}
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
static CoglAttributeBuffer *
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
upload_vertices (CoglJournal *journal,
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
const CoglJournalEntry *entries,
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
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
{
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
CoglAttributeBuffer *attribute_buffer;
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
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;
journal: avoiding some _cogl_matrix_entry_get()'s When uploading the vertices the journal calls _cogl_matrix_entry_get() to get a CoglMatrix for each journal entry so that it can so a software transform. Since _cogl_matrix_entry_get() can be a performance hot-spot and since it's trivial to keep track of the last CoglMatrixEntry seen we now avoid repeatedly calling _cogl_matrix_entry_get() for sequential entries with the same transform. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 70cad61533316e2303b8e188f2f361701dfb0c61)
2012-04-03 08:32:47 -04:00
CoglMatrixEntry *last_modelview_entry = NULL;
CoglMatrix 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
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: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
attribute_buffer = create_attribute_buffer (journal, needed_vbo_len * 4);
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
buffer = COGL_BUFFER (attribute_buffer);
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_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
Use cogl_buffer_map_range from the journal The journal maintains a cache of attribute buffers to upload the vertices for the rectangles. The buffers are mapped to fill in the data. However, if the previous journal was larger than the one being flushed now then the buffers may be larger than is actually needed. In that case we might as well only map the range that is actually used so that the driver can potentially avoid having to set up a mapping for the entire buffer. The COGL_BUFFER_MAP_HINT_DISCARD flag is still set so that the driver is free to discard the entire buffer, not just the subrange. The _cogl_buffer_map_for_fill_or_fallback has been replaced with _cogl_buffer_map_range_for_fill_or_fallback so that the range parameters can be passed. The original function is now just a wrapper around the latter. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 27769e54806dcfc1a12fdc4b07b054b8f2f4215b)
2012-10-17 16:36:10 -04:00
vout = _cogl_buffer_map_range_for_fill_or_fallback (buffer,
0, /* offset */
needed_vbo_len * 4);
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];
journal: avoiding some _cogl_matrix_entry_get()'s When uploading the vertices the journal calls _cogl_matrix_entry_get() to get a CoglMatrix for each journal entry so that it can so a software transform. Since _cogl_matrix_entry_get() can be a performance hot-spot and since it's trivial to keep track of the last CoglMatrixEntry seen we now avoid repeatedly calling _cogl_matrix_entry_get() for sequential entries with the same transform. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 70cad61533316e2303b8e188f2f361701dfb0c61)
2012-04-03 08:32:47 -04:00
if (entry->modelview_entry != last_modelview_entry)
_cogl_matrix_entry_get (entry->modelview_entry, &modelview);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
cogl_matrix_transform_points (&modelview,
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
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
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
return attribute_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
}
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;
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
if (journal->entries->len <= 0)
return;
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
for (i = 0; i < journal->entries->len; i++)
{
CoglJournalEntry *entry =
&g_array_index (journal->entries, CoglJournalEntry, i);
_cogl_pipeline_journal_unref (entry->pipeline);
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
_cogl_matrix_entry_unref (entry->modelview_entry);
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_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;
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
/* The journal only holds a reference to the framebuffer while the
journal is not empty */
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
cogl_object_unref (journal->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
}
/* Note: A return value of FALSE doesn't mean 'no' it means
* 'unknown' */
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool
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_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++)
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool found_reference = 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
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: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
_cogl_journal_flush (CoglJournal *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
{
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglFramebuffer *framebuffer;
CoglContext *ctx;
[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;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
int i;
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 */);
journal: Add a uprof timer around the _flush() discard This adds a uprof timer around the _cogl_journal_discard() at the end of _cogl_journal_flush() since this sometimes takes a significant proportion of the time to flush the journal. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 14ffc3a197100be814452af2d0f839970353b04d)
2012-08-27 14:44:11 -04:00
COGL_STATIC_TIMER (discard_timer,
"Journal Flush", /* parent */
"flush: discard",
"The time spent discarding the Cogl journal after a flush",
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
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;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
framebuffer = journal->framebuffer;
ctx = framebuffer->context;
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... */
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
_cogl_framebuffer_flush_dependency_journals (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
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);
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 */
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
_cogl_framebuffer_flush_state (framebuffer,
framebuffer,
framebuffer: Optimize _cogl_framebuffer_flush_state() Previously the cost of _cogl_framebuffer_state_flush() would always scale by the total amount of state tracked by CoglFramebuffer even in cases where we knew up-front that we only wanted to flush a subset of the state or in cases where we requested to flush the same framebuffer multiple times with no changes being made to the framebuffer. We now track a set of state changed flags with each framebuffer and track the current read/draw buffers as part of the CoglContext so that we can quickly bail out when asked to flush the same framebuffer multiple times with no changes. _cogl_framebuffer_flush_state() now takes a mask of the state that we want to flush and the implementation has been redesigned so that the cost of checking what needs to be flushed and flushing those changes now scales by how much state we actually plan to update. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-11-21 10:53:40 -05:00
COGL_FRAMEBUFFER_STATE_ALL &
~(COGL_FRAMEBUFFER_STATE_MODELVIEW |
COGL_FRAMEBUFFER_STATE_CLIP));
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.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-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 */
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
state.attribute_buffer =
upload_vertices (journal,
&g_array_index (journal->entries, CoglJournalEntry, 0),
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);
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 10:01:41 -05:00
cogl_object_unref (state.attribute_buffer);
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
journal: Add a uprof timer around the _flush() discard This adds a uprof timer around the _cogl_journal_discard() at the end of _cogl_journal_flush() since this sometimes takes a significant proportion of the time to flush the journal. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 14ffc3a197100be814452af2d0f839970353b04d)
2012-08-27 14:44:11 -04:00
COGL_TIMER_START (_cogl_uprof_context, discard_timer);
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: Add a uprof timer around the _flush() discard This adds a uprof timer around the _cogl_journal_discard() at the end of _cogl_journal_flush() since this sometimes takes a significant proportion of the time to flush the journal. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 14ffc3a197100be814452af2d0f839970353b04d)
2012-08-27 14:44:11 -04:00
COGL_TIMER_STOP (_cogl_uprof_context, discard_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
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
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
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
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;
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *texture = _cogl_pipeline_layer_get_texture_real (layer);
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
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,
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *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)
{
Adds cogl_framebuffer_draw_[*_]rectangle functions This adds experimental 2.0 api replacements for the cogl_rectangle[_*] functions that don't depend on having a current pipeline set on the context via cogl_{set,push}_source() or having a current framebuffer set on the context via cogl_push_framebuffer(). The aim for 2.0 is to switch away from having a statefull context that affects drawing to having framebuffer drawing apis that are explicitly passed a framebuffer and pipeline. To test this change several of the conformance tests were updated to use this api instead of cogl_rectangle and cogl_rectangle_with_texture_coords. Since it's quite laborious going through all of the conformance tests the opportunity was taken to make other clean ups in the conformance tests to replace other uses of 1.x api with experimental 2.0 api so long as that didn't affect what was being tested.
2012-03-16 15:54:13 -04:00
CoglFramebuffer *framebuffer = journal->framebuffer;
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
size_t stride;
Adds cogl_framebuffer_draw_[*_]rectangle functions This adds experimental 2.0 api replacements for the cogl_rectangle[_*] functions that don't depend on having a current pipeline set on the context via cogl_{set,push}_source() or having a current framebuffer set on the context via cogl_push_framebuffer(). The aim for 2.0 is to switch away from having a statefull context that affects drawing to having framebuffer drawing apis that are explicitly passed a framebuffer and pipeline. To test this change several of the conformance tests were updated to use this api instead of cogl_rectangle and cogl_rectangle_with_texture_coords. Since it's quite laborious going through all of the conformance tests the opportunity was taken to make other clean ups in the conformance tests to replace other uses of 1.x api with experimental 2.0 api so long as that didn't affect what was being tested.
2012-03-16 15:54:13 -04:00
int next_vert;
float *v;
int i;
int next_entry;
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
uint32_t disable_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
CoglJournalEntry *entry;
Adds cogl_framebuffer_draw_[*_]rectangle functions This adds experimental 2.0 api replacements for the cogl_rectangle[_*] functions that don't depend on having a current pipeline set on the context via cogl_{set,push}_source() or having a current framebuffer set on the context via cogl_push_framebuffer(). The aim for 2.0 is to switch away from having a statefull context that affects drawing to having framebuffer drawing apis that are explicitly passed a framebuffer and pipeline. To test this change several of the conformance tests were updated to use this api instead of cogl_rectangle and cogl_rectangle_with_texture_coords. Since it's quite laborious going through all of the conformance tests the opportunity was taken to make other clean ups in the conformance tests to replace other uses of 1.x api with experimental 2.0 api so long as that didn't affect what was being tested.
2012-03-16 15:54:13 -04:00
CoglPipeline *final_pipeline;
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;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
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 (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
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);
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
/* If the framebuffer was previously empty then we'll take a
reference to the current framebuffer. This reference will be
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
removed when the journal is flushed */
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
if (journal->vertices->len == 0)
Adds cogl_framebuffer_draw_[*_]rectangle functions This adds experimental 2.0 api replacements for the cogl_rectangle[_*] functions that don't depend on having a current pipeline set on the context via cogl_{set,push}_source() or having a current framebuffer set on the context via cogl_push_framebuffer(). The aim for 2.0 is to switch away from having a statefull context that affects drawing to having framebuffer drawing apis that are explicitly passed a framebuffer and pipeline. To test this change several of the conformance tests were updated to use this api instead of cogl_rectangle and cogl_rectangle_with_texture_coords. Since it's quite laborious going through all of the conformance tests the opportunity was taken to make other clean ups in the conformance tests to replace other uses of 1.x api with experimental 2.0 api so long as that didn't affect what was being tested.
2012-03-16 15:54:13 -04:00
cogl_object_ref (framebuffer);
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05: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
/* 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: */
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
_cogl_pipeline_get_colorubv (pipeline, (uint8_t *) v);
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
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);
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
_cogl_journal_dump_logged_quad ((uint8_t *)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
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
final_pipeline = 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: 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
{
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
final_pipeline = cogl_pipeline_copy (pipeline);
_cogl_pipeline_apply_overrides (final_pipeline, &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
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
entry->pipeline = _cogl_pipeline_journal_ref (final_pipeline);
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
Adds cogl_framebuffer_draw_[*_]rectangle functions This adds experimental 2.0 api replacements for the cogl_rectangle[_*] functions that don't depend on having a current pipeline set on the context via cogl_{set,push}_source() or having a current framebuffer set on the context via cogl_push_framebuffer(). The aim for 2.0 is to switch away from having a statefull context that affects drawing to having framebuffer drawing apis that are explicitly passed a framebuffer and pipeline. To test this change several of the conformance tests were updated to use this api instead of cogl_rectangle and cogl_rectangle_with_texture_coords. Since it's quite laborious going through all of the conformance tests the opportunity was taken to make other clean ups in the conformance tests to replace other uses of 1.x api with experimental 2.0 api so long as that didn't affect what was being tested.
2012-03-16 15:54:13 -04:00
clip_stack = _cogl_framebuffer_get_clip_stack (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
journal: use pipeline term instead of source Since we are adapting the Cogl api to be less stateful one of the things we no longer require is the cogl_set_source() api since a pipeline can be explicitly passed as an argument when drawing. This means the term "source" has been deprecated and internally we should aim to consistently use the term "pipeline" instead. This patch updates the journal code to use the term pipeline instead of source. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-01-07 22:00:57 -05:00
if (G_UNLIKELY (final_pipeline != pipeline))
Removes all remaining use of CoglHandle Removing CoglHandle has been an on going goal for quite a long time now and finally this patch removes the last remaining uses of the CoglHandle type and the cogl_handle_ apis. Since the big remaining users of CoglHandle were the cogl_program_ and cogl_shader_ apis which have replaced with the CoglSnippets api this patch removes both of these apis. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6ed3aaf4be21d605a1ed3176b3ea825933f85cf0) Since the original patch was done after removing deprecated API this back ported patch doesn't affect deprecated API and so actually this cherry-pick doesn't remove all remaining use of CoglHandle as it did for the master branch of Cogl.
2012-04-16 09:14:10 -04:00
cogl_object_unref (final_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
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
modelview_stack =
_cogl_framebuffer_get_modelview_stack (framebuffer);
entry->modelview_entry = _cogl_matrix_entry_ref (modelview_stack->last_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
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,
Adds cogl_framebuffer_draw_[*_]rectangle functions This adds experimental 2.0 api replacements for the cogl_rectangle[_*] functions that don't depend on having a current pipeline set on the context via cogl_{set,push}_source() or having a current framebuffer set on the context via cogl_push_framebuffer(). The aim for 2.0 is to switch away from having a statefull context that affects drawing to having framebuffer drawing apis that are explicitly passed a framebuffer and pipeline. To test this change several of the conformance tests were updated to use this api instead of cogl_rectangle and cogl_rectangle_with_texture_coords. Since it's quite laborious going through all of the conformance tests the opportunity was taken to make other clean ups in the conformance tests to replace other uses of 1.x api with experimental 2.0 api so long as that didn't affect what was being tested.
2012-03-16 15:54:13 -04: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-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)))
journal: Always keep a pointer back to the framebuffer Previously when adding a quad to the journal it would assume the journal belongs to the framebuffer at the top of the framebuffer stack and store a reference to that. We eventually want to get rid of the framebuffer stack so we should avoid using it here. The journal now takes a pointer back to the framebuffer in its constructor and it always retains the pointer. As was done previously, the journal still does not take a reference on the framebuffer unless it is non-empty so it does not create a permanent circular reference. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-16 13:26:30 -04:00
_cogl_journal_flush (journal);
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
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
entry_to_screen_polygon (CoglFramebuffer *framebuffer,
const CoglJournalEntry *entry,
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
float *vertices,
float *poly)
{
size_t array_stride =
GET_JOURNAL_ARRAY_STRIDE_FOR_N_LAYERS (entry->n_layers);
CoglMatrixStack *projection_stack;
CoglMatrix projection;
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglMatrix modelview;
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
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...
*/
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
_cogl_matrix_entry_get (entry->modelview_entry, &modelview);
cogl_matrix_transform_points (&modelview,
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
2, /* n_components */
sizeof (float) * 4, /* stride_in */
poly, /* points_in */
/* strideout */
sizeof (float) * 4,
poly, /* points_out */
4 /* n_points */);
projection_stack =
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
_cogl_framebuffer_get_projection_stack (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: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
cogl_framebuffer_get_viewport4fv (framebuffer, viewport);
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
/* 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
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
try_checking_point_hits_entry_after_clipping (CoglFramebuffer *framebuffer,
CoglJournalEntry *entry,
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
float *vertices,
float x,
float y,
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool *hit)
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
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool can_software_clip = TRUE;
CoglBool needs_software_clip = 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
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);
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
entry_to_screen_polygon (framebuffer, entry, vertices, poly);
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
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;
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool
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_try_read_pixel (CoglJournal *journal,
int x,
int y,
Add a public cogl_framebuffer_read_pixels_into_bitmap This adds a public function to read pixels from a framebuffer into a CoglBitmap. This replaces the internal function _cogl_read_pixels_with_rowstride because a CoglBitmap contains a rowstride so it can be used for the same purpose. A CoglBitmap already has public API to make one that points to a CoglPixelBuffer so this function can be used to read pixels into a PBO. It also avoids the need to push the framebuffer on to the context's stack so it provides a function which can be used in the 2.0 API after the stack is removed. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 14:23:51 -05:00
CoglBitmap *bitmap,
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool *found_intersection)
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
{
Add a public cogl_framebuffer_read_pixels_into_bitmap This adds a public function to read pixels from a framebuffer into a CoglBitmap. This replaces the internal function _cogl_read_pixels_with_rowstride because a CoglBitmap contains a rowstride so it can be used for the same purpose. A CoglBitmap already has public API to make one that points to a CoglPixelBuffer so this function can be used to read pixels into a PBO. It also avoids the need to push the framebuffer on to the context's stack so it provides a function which can be used in the 2.0 API after the stack is removed. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 14:23:51 -05:00
CoglPixelFormat format;
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
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;
Make _cogl_bitmap_get_{width,height,format,rowstride} public This are now marked as public experimental Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 15:18:05 -05:00
format = cogl_bitmap_get_format (bitmap);
Add a public cogl_framebuffer_read_pixels_into_bitmap This adds a public function to read pixels from a framebuffer into a CoglBitmap. This replaces the internal function _cogl_read_pixels_with_rowstride because a CoglBitmap contains a rowstride so it can be used for the same purpose. A CoglBitmap already has public API to make one that points to a CoglPixelBuffer so this function can be used to read pixels into a PBO. It also avoids the need to push the framebuffer on to the context's stack so it provides a function which can be used in the 2.0 API after the stack is removed. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 14:23:51 -05: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
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);
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
uint8_t *color = (uint8_t *)&g_array_index (journal->vertices, float,
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
entry->array_offset);
float *vertices = (float *)color + 1;
float poly[16];
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
CoglFramebuffer *framebuffer = journal->framebuffer;
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
uint8_t *pixel;
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
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
entry_to_screen_polygon (framebuffer, entry, vertices, poly);
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
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;
if (entry->clip_stack)
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool hit;
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
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
if (!try_checking_point_hits_entry_after_clipping (framebuffer,
entry,
vertices,
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
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;
Add a public cogl_framebuffer_read_pixels_into_bitmap This adds a public function to read pixels from a framebuffer into a CoglBitmap. This replaces the internal function _cogl_read_pixels_with_rowstride because a CoglBitmap contains a rowstride so it can be used for the same purpose. A CoglBitmap already has public API to make one that points to a CoglPixelBuffer so this function can be used to read pixels into a PBO. It also avoids the need to push the framebuffer on to the context's stack so it provides a function which can be used in the 2.0 API after the stack is removed. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 14:23:51 -05:00
pixel = _cogl_bitmap_map (bitmap,
COGL_BUFFER_ACCESS_WRITE,
COGL_BUFFER_MAP_HINT_DISCARD);
if (pixel == NULL)
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
pixel[0] = color[0];
pixel[1] = color[1];
pixel[2] = color[2];
pixel[3] = color[3];
Add a public cogl_framebuffer_read_pixels_into_bitmap This adds a public function to read pixels from a framebuffer into a CoglBitmap. This replaces the internal function _cogl_read_pixels_with_rowstride because a CoglBitmap contains a rowstride so it can be used for the same purpose. A CoglBitmap already has public API to make one that points to a CoglPixelBuffer so this function can be used to read pixels into a PBO. It also avoids the need to push the framebuffer on to the context's stack so it provides a function which can be used in the 2.0 API after the stack is removed. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 14:23:51 -05:00
_cogl_bitmap_unmap (bitmap);
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
goto success;
}
success:
journal->fast_read_pixel_count++;
return TRUE;
}
Reference in New Issue Copy Permalink