mutter/cogl/cogl.c

880 lines
22 KiB
C
Raw Normal View History

/*
* 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
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
* Boston, MA 02111-1307, USA.
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "cogl.h"
#include <string.h>
#include <math.h>
#include <stdlib.h>
Intial Re-layout of the Cogl source code and introduction of a Cogl Winsys As part of an incremental process to have Cogl be a standalone project we want to re-consider how we organise the Cogl source code. Currently this is the structure I'm aiming for: cogl/ cogl/ <put common source here> winsys/ cogl-glx.c cogl-wgl.c driver/ gl/ gles/ os/ ? utils/ cogl-fixed cogl-matrix-stack? cogl-journal? cogl-primitives? pango/ The new winsys component is a starting point for migrating window system code (i.e. x11,glx,wgl,osx,egl etc) from Clutter to Cogl. The utils/ and pango/ directories aren't added by this commit, but they are noted because I plan to add them soon. Overview of the planned structure: * The winsys/ API is the API that binds OpenGL to a specific window system, be that X11 or win32 etc. Example are glx, wgl and egl. Much of the logic under clutter/{glx,osx,win32 etc} should migrate here. * Note there is also the idea of a winsys-base that may represent a window system for which there are multiple winsys APIs. An example of this is x11, since glx and egl may both be used with x11. (currently only Clutter has the idea of a winsys-base) * The driver/ represents a specific varient of OpenGL. Currently we have "gl" representing OpenGL 1.4-2.1 (mostly fixed function) and "gles" representing GLES 1.1 (fixed funciton) and 2.0 (fully shader based) * Everything under cogl/ should fundamentally be supporting access to the GPU. Essentially Cogl's most basic requirement is to provide a nice GPU Graphics API and drawing a line between this and the utility functionality we add to support Clutter should help keep this lean and maintainable. * Code under utils/ as suggested builds on cogl/ adding more convenient APIs or mechanism to optimize special cases. Broadly speaking you can compare cogl/ to OpenGL and utils/ to GLU. * clutter/pango will be moved to clutter/cogl/pango How some of the internal configure.ac/pkg-config terminology has changed: backendextra -> CLUTTER_WINSYS_BASE # e.g. "x11" backendextralib -> CLUTTER_WINSYS_BASE_LIB # e.g. "x11/libclutter-x11.la" clutterbackend -> {CLUTTER,COGL}_WINSYS # e.g. "glx" CLUTTER_FLAVOUR -> {CLUTTER,COGL}_WINSYS clutterbackendlib -> CLUTTER_WINSYS_LIB CLUTTER_COGL -> COGL_DRIVER # e.g. "gl" Note: The CLUTTER_FLAVOUR and CLUTTER_COGL defines are kept for apps As the first thing to take advantage of the new winsys component in Cogl; cogl_get_proc_address() has been moved from cogl/{gl,gles}/cogl.c into cogl/common/cogl.c and this common implementation first trys _cogl_winsys_get_proc_address() but if that fails then it falls back to gmodule.
2009-07-28 01:02:02 +00:00
#include <gmodule.h>
#include "cogl-debug.h"
#include "cogl-internal.h"
#include "cogl-util.h"
#include "cogl-context.h"
#include "cogl-material-private.h"
Intial Re-layout of the Cogl source code and introduction of a Cogl Winsys As part of an incremental process to have Cogl be a standalone project we want to re-consider how we organise the Cogl source code. Currently this is the structure I'm aiming for: cogl/ cogl/ <put common source here> winsys/ cogl-glx.c cogl-wgl.c driver/ gl/ gles/ os/ ? utils/ cogl-fixed cogl-matrix-stack? cogl-journal? cogl-primitives? pango/ The new winsys component is a starting point for migrating window system code (i.e. x11,glx,wgl,osx,egl etc) from Clutter to Cogl. The utils/ and pango/ directories aren't added by this commit, but they are noted because I plan to add them soon. Overview of the planned structure: * The winsys/ API is the API that binds OpenGL to a specific window system, be that X11 or win32 etc. Example are glx, wgl and egl. Much of the logic under clutter/{glx,osx,win32 etc} should migrate here. * Note there is also the idea of a winsys-base that may represent a window system for which there are multiple winsys APIs. An example of this is x11, since glx and egl may both be used with x11. (currently only Clutter has the idea of a winsys-base) * The driver/ represents a specific varient of OpenGL. Currently we have "gl" representing OpenGL 1.4-2.1 (mostly fixed function) and "gles" representing GLES 1.1 (fixed funciton) and 2.0 (fully shader based) * Everything under cogl/ should fundamentally be supporting access to the GPU. Essentially Cogl's most basic requirement is to provide a nice GPU Graphics API and drawing a line between this and the utility functionality we add to support Clutter should help keep this lean and maintainable. * Code under utils/ as suggested builds on cogl/ adding more convenient APIs or mechanism to optimize special cases. Broadly speaking you can compare cogl/ to OpenGL and utils/ to GLU. * clutter/pango will be moved to clutter/cogl/pango How some of the internal configure.ac/pkg-config terminology has changed: backendextra -> CLUTTER_WINSYS_BASE # e.g. "x11" backendextralib -> CLUTTER_WINSYS_BASE_LIB # e.g. "x11/libclutter-x11.la" clutterbackend -> {CLUTTER,COGL}_WINSYS # e.g. "glx" CLUTTER_FLAVOUR -> {CLUTTER,COGL}_WINSYS clutterbackendlib -> CLUTTER_WINSYS_LIB CLUTTER_COGL -> COGL_DRIVER # e.g. "gl" Note: The CLUTTER_FLAVOUR and CLUTTER_COGL defines are kept for apps As the first thing to take advantage of the new winsys component in Cogl; cogl_get_proc_address() has been moved from cogl/{gl,gles}/cogl.c into cogl/common/cogl.c and this common implementation first trys _cogl_winsys_get_proc_address() but if that fails then it falls back to gmodule.
2009-07-28 01:02:02 +00:00
#include "cogl-winsys.h"
#if defined (HAVE_COGL_GLES2) || defined (HAVE_COGL_GLES)
#include "cogl-gles2-wrapper.h"
#endif
#ifdef HAVE_COGL_GL
#define glClientActiveTexture ctx->drv.pf_glClientActiveTexture
#endif
#ifdef COGL_GL_DEBUG
/* GL error to string conversion */
static const struct {
GLuint error_code;
const gchar *error_string;
} gl_errors[] = {
{ GL_NO_ERROR, "No error" },
{ GL_INVALID_ENUM, "Invalid enumeration value" },
{ GL_INVALID_VALUE, "Invalid value" },
{ GL_INVALID_OPERATION, "Invalid operation" },
{ GL_STACK_OVERFLOW, "Stack overflow" },
{ GL_STACK_UNDERFLOW, "Stack underflow" },
{ GL_OUT_OF_MEMORY, "Out of memory" },
#ifdef GL_INVALID_FRAMEBUFFER_OPERATION_EXT
{ GL_INVALID_FRAMEBUFFER_OPERATION_EXT, "Invalid framebuffer operation" }
#endif
};
static const guint n_gl_errors = G_N_ELEMENTS (gl_errors);
const gchar *
cogl_gl_error_to_string (GLenum error_code)
{
gint i;
for (i = 0; i < n_gl_errors; i++)
{
if (gl_errors[i].error_code == error_code)
return gl_errors[i].error_string;
}
return "Unknown GL error";
}
#endif /* COGL_GL_DEBUG */
Intial Re-layout of the Cogl source code and introduction of a Cogl Winsys As part of an incremental process to have Cogl be a standalone project we want to re-consider how we organise the Cogl source code. Currently this is the structure I'm aiming for: cogl/ cogl/ <put common source here> winsys/ cogl-glx.c cogl-wgl.c driver/ gl/ gles/ os/ ? utils/ cogl-fixed cogl-matrix-stack? cogl-journal? cogl-primitives? pango/ The new winsys component is a starting point for migrating window system code (i.e. x11,glx,wgl,osx,egl etc) from Clutter to Cogl. The utils/ and pango/ directories aren't added by this commit, but they are noted because I plan to add them soon. Overview of the planned structure: * The winsys/ API is the API that binds OpenGL to a specific window system, be that X11 or win32 etc. Example are glx, wgl and egl. Much of the logic under clutter/{glx,osx,win32 etc} should migrate here. * Note there is also the idea of a winsys-base that may represent a window system for which there are multiple winsys APIs. An example of this is x11, since glx and egl may both be used with x11. (currently only Clutter has the idea of a winsys-base) * The driver/ represents a specific varient of OpenGL. Currently we have "gl" representing OpenGL 1.4-2.1 (mostly fixed function) and "gles" representing GLES 1.1 (fixed funciton) and 2.0 (fully shader based) * Everything under cogl/ should fundamentally be supporting access to the GPU. Essentially Cogl's most basic requirement is to provide a nice GPU Graphics API and drawing a line between this and the utility functionality we add to support Clutter should help keep this lean and maintainable. * Code under utils/ as suggested builds on cogl/ adding more convenient APIs or mechanism to optimize special cases. Broadly speaking you can compare cogl/ to OpenGL and utils/ to GLU. * clutter/pango will be moved to clutter/cogl/pango How some of the internal configure.ac/pkg-config terminology has changed: backendextra -> CLUTTER_WINSYS_BASE # e.g. "x11" backendextralib -> CLUTTER_WINSYS_BASE_LIB # e.g. "x11/libclutter-x11.la" clutterbackend -> {CLUTTER,COGL}_WINSYS # e.g. "glx" CLUTTER_FLAVOUR -> {CLUTTER,COGL}_WINSYS clutterbackendlib -> CLUTTER_WINSYS_LIB CLUTTER_COGL -> COGL_DRIVER # e.g. "gl" Note: The CLUTTER_FLAVOUR and CLUTTER_COGL defines are kept for apps As the first thing to take advantage of the new winsys component in Cogl; cogl_get_proc_address() has been moved from cogl/{gl,gles}/cogl.c into cogl/common/cogl.c and this common implementation first trys _cogl_winsys_get_proc_address() but if that fails then it falls back to gmodule.
2009-07-28 01:02:02 +00:00
CoglFuncPtr
cogl_get_proc_address (const gchar* name)
{
void *address;
static GModule *module = NULL;
address = _cogl_winsys_get_proc_address (name);
if (address)
return address;
/* this should find the right function if the program is linked against a
* library providing it */
if (module == NULL)
module = g_module_open (NULL, G_MODULE_BIND_LAZY | G_MODULE_BIND_LOCAL);
if (module)
{
gpointer symbol;
if (g_module_symbol (module, name, &symbol))
return symbol;
}
return NULL;
}
void
cogl_clear (const CoglColor *color, gulong buffers)
{
GLbitfield gl_buffers = 0;
COGL_NOTE (DRAW, "Clear begin");
cogl_clip_ensure ();
if (buffers & COGL_BUFFER_BIT_COLOR)
{
GE( glClearColor (cogl_color_get_red_float (color),
cogl_color_get_green_float (color),
cogl_color_get_blue_float (color),
cogl_color_get_alpha_float (color)) );
gl_buffers |= GL_COLOR_BUFFER_BIT;
}
if (buffers & COGL_BUFFER_BIT_DEPTH)
gl_buffers |= GL_DEPTH_BUFFER_BIT;
if (buffers & COGL_BUFFER_BIT_STENCIL)
gl_buffers |= GL_STENCIL_BUFFER_BIT;
if (!gl_buffers)
{
static gboolean shown = FALSE;
if (!shown)
{
g_warning ("You should specify at least one auxiliary buffer "
"when calling cogl_clear");
}
return;
}
glClear (gl_buffers);
COGL_NOTE (DRAW, "Clear end");
}
static inline gboolean
cogl_toggle_flag (CoglContext *ctx,
gulong new_flags,
gulong flag,
GLenum gl_flag)
{
/* Toggles and caches a single enable flag on or off
* by comparing to current state
*/
if (new_flags & flag)
{
if (!(ctx->enable_flags & flag))
{
GE( glEnable (gl_flag) );
ctx->enable_flags |= flag;
return TRUE;
}
}
else if (ctx->enable_flags & flag)
{
GE( glDisable (gl_flag) );
ctx->enable_flags &= ~flag;
}
return FALSE;
}
static inline gboolean
cogl_toggle_client_flag (CoglContext *ctx,
gulong new_flags,
gulong flag,
GLenum gl_flag)
{
/* Toggles and caches a single client-side enable flag
* on or off by comparing to current state
*/
if (new_flags & flag)
{
if (!(ctx->enable_flags & flag))
{
GE( glEnableClientState (gl_flag) );
ctx->enable_flags |= flag;
return TRUE;
}
}
else if (ctx->enable_flags & flag)
{
GE( glDisableClientState (gl_flag) );
ctx->enable_flags &= ~flag;
}
return FALSE;
}
void
cogl_enable (gulong flags)
{
/* This function essentially caches glEnable state() in the
* hope of lessening number GL traffic.
*/
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
cogl_toggle_flag (ctx, flags,
COGL_ENABLE_BLEND,
GL_BLEND);
cogl_toggle_flag (ctx, flags,
COGL_ENABLE_BACKFACE_CULLING,
GL_CULL_FACE);
cogl_toggle_client_flag (ctx, flags,
COGL_ENABLE_VERTEX_ARRAY,
GL_VERTEX_ARRAY);
cogl_toggle_client_flag (ctx, flags,
COGL_ENABLE_COLOR_ARRAY,
GL_COLOR_ARRAY);
}
gulong
cogl_get_enable ()
{
_COGL_GET_CONTEXT (ctx, 0);
return ctx->enable_flags;
}
void
cogl_set_depth_test_enabled (gboolean setting)
{
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
/* Currently the journal can't track changes to depth state... */
_cogl_journal_flush ();
if (setting)
{
glEnable (GL_DEPTH_TEST);
glDepthFunc (GL_LEQUAL);
}
else
glDisable (GL_DEPTH_TEST);
}
gboolean
cogl_get_depth_test_enabled (void)
{
return glIsEnabled (GL_DEPTH_TEST) == GL_TRUE ? TRUE : FALSE;
}
void
cogl_set_backface_culling_enabled (gboolean setting)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
/* Currently the journal can't track changes to backface culling state... */
_cogl_journal_flush ();
ctx->enable_backface_culling = setting;
}
gboolean
cogl_get_backface_culling_enabled (void)
{
_COGL_GET_CONTEXT (ctx, FALSE);
return ctx->enable_backface_culling;
}
void
cogl_set_source_color (const CoglColor *color)
{
CoglColor premultiplied;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* In case cogl_set_source_texture was previously used... */
cogl_material_remove_layer (ctx->default_material, 0);
premultiplied = *color;
cogl_color_premultiply (&premultiplied);
cogl_material_set_color (ctx->default_material, &premultiplied);
cogl_set_source (ctx->default_material);
}
static void
project_vertex (const CoglMatrix *modelview_matrix,
const CoglMatrix *projection_matrix,
float *vertex)
{
int i;
/* Apply the modelview matrix */
cogl_matrix_transform_point (modelview_matrix,
&vertex[0], &vertex[1],
&vertex[2], &vertex[3]);
/* Apply the projection matrix */
cogl_matrix_transform_point (projection_matrix,
&vertex[0], &vertex[1],
&vertex[2], &vertex[3]);
/* Convert from homogenized coordinates */
for (i = 0; i < 4; i++)
vertex[i] /= vertex[3];
}
static void
set_clip_plane (GLint plane_num,
const float *vertex_a,
const float *vertex_b)
{
#if defined (HAVE_COGL_GLES2) || defined (HAVE_COGL_GLES)
GLfloat plane[4];
#else
GLdouble plane[4];
#endif
GLfloat angle;
CoglMatrix inverse_projection;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* Calculate the angle between the axes and the line crossing the
two points */
angle = atan2f (vertex_b[1] - vertex_a[1],
vertex_b[0] - vertex_a[0]) * (180.0/G_PI);
_cogl_current_matrix_push ();
/* Load the identity matrix and multiply by the reverse of the
projection matrix so we can specify the plane in screen
coordinates */
_cogl_current_matrix_identity ();
cogl_matrix_init_from_array (&inverse_projection,
ctx->inverse_projection);
_cogl_current_matrix_multiply (&inverse_projection);
/* Rotate about point a */
_cogl_current_matrix_translate (vertex_a[0], vertex_a[1], vertex_a[2]);
/* Rotate the plane by the calculated angle so that it will connect
the two points */
_cogl_current_matrix_rotate (angle, 0.0f, 0.0f, 1.0f);
_cogl_current_matrix_translate (-vertex_a[0], -vertex_a[1], -vertex_a[2]);
_cogl_flush_matrix_stacks ();
plane[0] = 0;
plane[1] = -1.0;
plane[2] = 0;
plane[3] = vertex_a[1];
#if defined (HAVE_COGL_GLES2) || defined (HAVE_COGL_GLES)
GE( glClipPlanef (plane_num, plane) );
#else
GE( glClipPlane (plane_num, plane) );
#endif
_cogl_current_matrix_pop ();
}
void
_cogl_set_clip_planes (float x_offset,
float y_offset,
float width,
float height)
{
CoglMatrix modelview_matrix;
CoglMatrix projection_matrix;
float vertex_tl[4] = { x_offset, y_offset, 0, 1.0 };
float vertex_tr[4] = { x_offset + width, y_offset, 0, 1.0 };
float vertex_bl[4] = { x_offset, y_offset + height, 0, 1.0 };
float vertex_br[4] = { x_offset + width, y_offset + height,
0, 1.0 };
_cogl_get_matrix (COGL_MATRIX_PROJECTION,
&projection_matrix);
_cogl_get_matrix (COGL_MATRIX_MODELVIEW,
&modelview_matrix);
project_vertex (&modelview_matrix, &projection_matrix, vertex_tl);
project_vertex (&modelview_matrix, &projection_matrix, vertex_tr);
project_vertex (&modelview_matrix, &projection_matrix, vertex_bl);
project_vertex (&modelview_matrix, &projection_matrix, vertex_br);
/* If the order of the top and bottom lines is different from the
order of the left and right lines then the clip rect must have
been transformed so that the back is visible. We therefore need
to swap one pair of vertices otherwise all of the planes will be
the wrong way around */
if ((vertex_tl[0] < vertex_tr[0] ? 1 : 0)
!= (vertex_bl[1] < vertex_tl[1] ? 1 : 0))
{
float temp[4];
memcpy (temp, vertex_tl, sizeof (temp));
memcpy (vertex_tl, vertex_tr, sizeof (temp));
memcpy (vertex_tr, temp, sizeof (temp));
memcpy (temp, vertex_bl, sizeof (temp));
memcpy (vertex_bl, vertex_br, sizeof (temp));
memcpy (vertex_br, temp, sizeof (temp));
}
set_clip_plane (GL_CLIP_PLANE0, vertex_tl, vertex_tr);
set_clip_plane (GL_CLIP_PLANE1, vertex_tr, vertex_br);
set_clip_plane (GL_CLIP_PLANE2, vertex_br, vertex_bl);
set_clip_plane (GL_CLIP_PLANE3, vertex_bl, vertex_tl);
}
void
_cogl_add_stencil_clip (float x_offset,
float y_offset,
float width,
float height,
gboolean first)
{
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
CoglHandle current_source;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
_cogl_journal_flush ();
/* temporarily swap in our special stenciling material */
current_source = cogl_handle_ref (ctx->source_material);
cogl_set_source (ctx->stencil_material);
if (first)
{
GE( glEnable (GL_STENCIL_TEST) );
/* Initially disallow everything */
GE( glClearStencil (0) );
GE( glClear (GL_STENCIL_BUFFER_BIT) );
/* Punch out a hole to allow the rectangle */
GE( glStencilFunc (GL_NEVER, 0x1, 0x1) );
GE( glStencilOp (GL_REPLACE, GL_REPLACE, GL_REPLACE) );
cogl_rectangle (x_offset, y_offset,
x_offset + width, y_offset + height);
}
else
{
/* Add one to every pixel of the stencil buffer in the
rectangle */
GE( glStencilFunc (GL_NEVER, 0x1, 0x3) );
GE( glStencilOp (GL_INCR, GL_INCR, GL_INCR) );
cogl_rectangle (x_offset, y_offset,
x_offset + width, y_offset + height);
/* Subtract one from all pixels in the stencil buffer so that
only pixels where both the original stencil buffer and the
rectangle are set will be valid */
GE( glStencilOp (GL_DECR, GL_DECR, GL_DECR) );
_cogl_set_current_matrix (COGL_MATRIX_PROJECTION);
_cogl_current_matrix_push ();
_cogl_current_matrix_identity ();
/* Cogl generally assumes the modelview matrix is current, so since
* cogl_rectangle will be flushing GL state and emitting geometry
* to OpenGL it will be confused if we leave the projection matrix
* active... */
_cogl_set_current_matrix (COGL_MATRIX_MODELVIEW);
_cogl_current_matrix_push ();
_cogl_current_matrix_identity ();
cogl_rectangle (-1.0, -1.0, 1.0, 1.0);
_cogl_current_matrix_pop ();
_cogl_set_current_matrix (COGL_MATRIX_PROJECTION);
_cogl_current_matrix_pop ();
_cogl_set_current_matrix (COGL_MATRIX_MODELVIEW);
}
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
/* make sure our rectangles hit the stencil buffer before we restore
* the stencil function / operation */
_cogl_journal_flush ();
/* Restore the stencil mode */
GE( glStencilFunc (GL_EQUAL, 0x1, 0x1) );
GE( glStencilOp (GL_KEEP, GL_KEEP, GL_KEEP) );
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
/* restore the original source material */
cogl_set_source (current_source);
cogl_handle_unref (current_source);
}
void
_cogl_disable_stencil_buffer (void)
{
GE( glDisable (GL_STENCIL_TEST) );
}
void
_cogl_enable_clip_planes (void)
{
GE( glEnable (GL_CLIP_PLANE0) );
GE( glEnable (GL_CLIP_PLANE1) );
GE( glEnable (GL_CLIP_PLANE2) );
GE( glEnable (GL_CLIP_PLANE3) );
}
void
_cogl_disable_clip_planes (void)
{
GE( glDisable (GL_CLIP_PLANE3) );
GE( glDisable (GL_CLIP_PLANE2) );
GE( glDisable (GL_CLIP_PLANE1) );
GE( glDisable (GL_CLIP_PLANE0) );
}
/* XXX: This should be deprecated and Cogl should be left to manage
* the glViewport automatically when switching draw buffers. */
void
cogl_viewport (guint width,
guint height)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
COGL_NOTE (MISC, "glViewport(0, 0, %u, %u)", width, height);
GE( glViewport (0, 0, width, height) );
ctx->viewport_width = width;
ctx->viewport_height = height;
}
void
_cogl_setup_viewport (guint width,
guint height,
float fovy,
float aspect,
float z_near,
float z_far)
{
float z_camera;
CoglMatrix projection_matrix;
cogl_viewport (width, height);
/* For Ortho projection.
* _cogl_current_matrix_ortho (0, width, 0, height, -1, 1);
*/
cogl_perspective (fovy, aspect, z_near, z_far);
/*
* In theory, we can compute the camera distance from screen as:
*
* 0.5 * tan (FOV)
*
* However, it's better to compute the z_camera from our projection
* matrix so that we get a 1:1 mapping at the screen distance. Consider
* the upper-left corner of the screen. It has object coordinates
* (0,0,0), so by the transform below, ends up with eye coordinate
*
* x_eye = x_object / width - 0.5 = - 0.5
* y_eye = (height - y_object) / width - 0.5 = 0.5
* z_eye = z_object / width - z_camera = - z_camera
*
* From cogl_perspective(), we know that the projection matrix has
* the form:
*
* (x, 0, 0, 0)
* (0, y, 0, 0)
* (0, 0, c, d)
* (0, 0, -1, 0)
*
* Applied to the above, we get clip coordinates of
*
* x_clip = x * (- 0.5)
* y_clip = y * 0.5
* w_clip = - 1 * (- z_camera) = z_camera
*
* Dividing through by w to get normalized device coordinates, we
* have, x_nd = x * 0.5 / z_camera, y_nd = - y * 0.5 / z_camera.
* The upper left corner of the screen has normalized device coordinates,
* (-1, 1), so to have the correct 1:1 mapping, we have to have:
*
* z_camera = 0.5 * x = 0.5 * y
*
* If x != y, then we have a non-uniform aspect ration, and a 1:1 mapping
* doesn't make sense.
*/
cogl_get_projection_matrix (&projection_matrix);
z_camera = 0.5 * projection_matrix.xx;
_cogl_set_current_matrix (COGL_MATRIX_MODELVIEW);
_cogl_current_matrix_identity ();
_cogl_current_matrix_translate (-0.5f, -0.5f, -z_camera);
_cogl_current_matrix_scale (1.0f / width, -1.0f / height, 1.0f / width);
_cogl_current_matrix_translate (0.0f, -1.0 * height, 0.0f);
}
CoglFeatureFlags
cogl_get_features (void)
{
_COGL_GET_CONTEXT (ctx, 0);
if (!ctx->features_cached)
_cogl_features_init ();
if (cogl_debug_flags & COGL_DEBUG_DISABLE_VBOS)
ctx->feature_flags &= ~COGL_FEATURE_VBOS;
return ctx->feature_flags;
}
gboolean
cogl_features_available (CoglFeatureFlags features)
{
_COGL_GET_CONTEXT (ctx, 0);
if (!ctx->features_cached)
_cogl_features_init ();
return (ctx->feature_flags & features) == features;
}
/* XXX: This function should be deprecated, and replaced with a
* cogl_draw_buffer_get_size() API instead. We don't support offset
* viewports, and you can't have floating point viewport sizes. */
void
cogl_get_viewport (float v[4])
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
v[0] = 0;
v[1] = 0;
v[2] = ctx->viewport_width;
v[3] = ctx->viewport_height;
}
void
cogl_get_bitmasks (gint *red,
gint *green,
gint *blue,
gint *alpha)
{
GLint value;
if (red)
{
GE( glGetIntegerv(GL_RED_BITS, &value) );
*red = value;
}
if (green)
{
GE( glGetIntegerv(GL_GREEN_BITS, &value) );
*green = value;
}
if (blue)
{
GE( glGetIntegerv(GL_BLUE_BITS, &value) );
*blue = value;
}
if (alpha)
{
GE( glGetIntegerv(GL_ALPHA_BITS, &value ) );
*alpha = value;
}
}
void
cogl_set_fog (const CoglColor *fog_color,
CoglFogMode mode,
float density,
float z_near,
float z_far)
{
GLfloat fogColor[4];
GLenum gl_mode = GL_LINEAR;
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
/* The cogl journal doesn't currently track fog state changes */
_cogl_journal_flush ();
fogColor[0] = cogl_color_get_red_float (fog_color);
fogColor[1] = cogl_color_get_green_float (fog_color);
fogColor[2] = cogl_color_get_blue_float (fog_color);
fogColor[3] = cogl_color_get_alpha_float (fog_color);
glEnable (GL_FOG);
glFogfv (GL_FOG_COLOR, fogColor);
#if HAVE_COGL_GLES
switch (mode)
{
case COGL_FOG_MODE_LINEAR:
gl_mode = GL_LINEAR;
break;
case COGL_FOG_MODE_EXPONENTIAL:
gl_mode = GL_EXP;
break;
case COGL_FOG_MODE_EXPONENTIAL_SQUARED:
gl_mode = GL_EXP2;
break;
}
#endif
/* TODO: support other modes for GLES2 */
/* NB: GLES doesn't have glFogi */
glFogf (GL_FOG_MODE, gl_mode);
glHint (GL_FOG_HINT, GL_NICEST);
glFogf (GL_FOG_DENSITY, (GLfloat) density);
glFogf (GL_FOG_START, (GLfloat) z_near);
glFogf (GL_FOG_END, (GLfloat) z_far);
}
void
cogl_disable_fog (void)
{
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
/* Currently the journal can't track changes to fog state... */
_cogl_journal_flush ();
glDisable (GL_FOG);
}
#if 0
void
cogl_flush_gl_state (int flags)
{
_cogl_flush_matrix_stacks ();
}
#endif
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
void
cogl_flush (void)
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
{
_cogl_journal_flush ();
}
void
cogl_read_pixels (int x,
int y,
int width,
int height,
CoglReadPixelsFlags source,
CoglPixelFormat format,
guint8 *pixels)
{
GLint viewport[4];
GLint viewport_height;
int rowstride = width * 4;
guint8 *temprow;
g_return_if_fail (format == COGL_PIXEL_FORMAT_RGBA_8888);
g_return_if_fail (source == COGL_READ_PIXELS_COLOR_BUFFER);
temprow = g_alloca (rowstride * sizeof (guint8));
glGetIntegerv (GL_VIEWPORT, viewport);
viewport_height = viewport[3];
/* The y co-ordinate should be given in OpenGL's coordinate system
so 0 is the bottom row */
y = viewport_height - y - height;
/* Setup the pixel store parameters that may have been changed by
Cogl */
glPixelStorei (GL_PACK_ALIGNMENT, 4);
#ifdef HAVE_COGL_GL
glPixelStorei (GL_PACK_ROW_LENGTH, 0);
glPixelStorei (GL_PACK_SKIP_PIXELS, 0);
glPixelStorei (GL_PACK_SKIP_ROWS, 0);
#endif /* HAVE_COGL_GL */
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
/* make sure any batched primitives get emitted to the GL driver before
* issuing our read pixels... */
cogl_flush ();
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes Previously the journal was always flushed at the end of _cogl_rectangles_with_multitexture_coords, (i.e. the end of any cogl_rectangle* calls) but now we have broadened the potential for batching geometry. In ideal circumstances we will only flush once per scene. In summary the journal works like this: When you use any of the cogl_rectangle* APIs then nothing is emitted to the GPU at this point, we just log one or more quads into the journal. A journal entry consists of the quad coordinates, an associated material reference, and a modelview matrix. Ideally the journal only gets flushed once at the end of a scene, but in fact there are things to consider that may cause unwanted flushing, including: - modifying materials mid-scene This is because each quad in the journal has an associated material reference (i.e. not copy), so if you try and modify a material that is already referenced in the journal we force a flush first) NOTE: For now this means you should avoid using cogl_set_source_color() since that currently uses a single shared material. Later we should change it to use a pool of materials that is recycled when the journal is flushed. - modifying any state that isn't currently logged, such as depth, fog and backface culling enables. The first thing that happens when flushing, is to upload all the vertex data associated with the journal into a single VBO. We then go through a process of splitting up the journal into batches that have compatible state so they can be emitted to the GPU together. This is currently broken up into 3 levels so we can stagger the state changes: 1) we break the journal up according to changes in the number of material layers associated with logged quads. The number of layers in a material determines the stride of the associated vertices, so we have to update our vertex array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc) 2) we further split batches up according to material compatability. (e.g. materials with different textures) We flush material state at this level. 3) Finally we split batches up according to modelview changes. At this level we update the modelview matrix and actually emit the actual draw command. This commit is largely about putting the initial design in-place; this will be followed by other changes that take advantage of the extended batching.
2009-06-17 17:46:42 +00:00
glReadPixels (x, y, width, height, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
/* TODO: consider using the GL_MESA_pack_invert extension in the future
* to avoid this flip... */
/* vertically flip the buffer in-place */
for (y = 0; y < height / 2; y++)
{
if (y != height - y - 1) /* skip center row */
{
memcpy (temprow,
pixels + y * rowstride, rowstride);
memcpy (pixels + y * rowstride,
pixels + (height - y - 1) * rowstride, rowstride);
memcpy (pixels + (height - y - 1) * rowstride,
temprow,
rowstride);
}
}
}
[cogl] Improve ability to break out into raw OpenGL via begin/end mechanism Although we wouldn't recommend developers try and interleve OpenGL drawing with Cogl drawing - we would prefer patches that improve Cogl to avoid this if possible - we are providing a simple mechanism that will at least give developers a fighting chance if they find it necissary. Note: we aren't helping developers change OpenGL state to modify the behaviour of Cogl drawing functions - it's unlikley that can ever be reliably supported - but if they are trying to do something like: - setup some OpenGL state. - draw using OpenGL (e.g. glDrawArrays() ) - reset modified OpenGL state. - continue using Cogl to draw They should surround their blocks of raw OpenGL with cogl_begin_gl() and cogl_end_gl(): cogl_begin_gl (); - setup some OpenGL state. - draw using OpenGL (e.g. glDrawArrays() ) - reset modified OpenGL state. cogl_end_gl (); - continue using Cogl to draw Again; we aren't supporting code like this: - setup some OpenGL state. - use Cogl to draw - reset modified OpenGL state. When the internals of Cogl evolves, this is very liable to break. cogl_begin_gl() will flush all internally batched Cogl primitives, and emit all internal Cogl state to OpenGL as if it were going to draw something itself. The result is that the OpenGL modelview matrix will be setup; the state corresponding to the current source material will be setup and other world state such as backface culling, depth and fogging enabledness will be also be sent to OpenGL. Note: no special material state is flushed, so if developers want Cogl to setup a simplified material state it is the their responsibility to set a simple source material before calling cogl_begin_gl. E.g. by calling cogl_set_source_color4ub(). Note: It is the developers responsibility to restore any OpenGL state that they modify to how it was after calling cogl_begin_gl() if they don't do this then the result of further Cogl calls is undefined.
2009-06-29 21:32:05 +00:00
void
cogl_begin_gl (void)
{
CoglMaterialFlushOptions options;
gulong enable_flags;
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (ctx->in_begin_gl_block)
{
static gboolean shown = FALSE;
if (!shown)
g_warning ("You should not nest cogl_begin_gl/cogl_end_gl blocks");
shown = TRUE;
return;
}
ctx->in_begin_gl_block = TRUE;
/* Flush all batched primitives */
cogl_flush ();
/* Flush our clipping state to GL */
cogl_clip_ensure ();
/* Flush any client side matrix state */
_cogl_flush_matrix_stacks ();
[cogl] Improve ability to break out into raw OpenGL via begin/end mechanism Although we wouldn't recommend developers try and interleve OpenGL drawing with Cogl drawing - we would prefer patches that improve Cogl to avoid this if possible - we are providing a simple mechanism that will at least give developers a fighting chance if they find it necissary. Note: we aren't helping developers change OpenGL state to modify the behaviour of Cogl drawing functions - it's unlikley that can ever be reliably supported - but if they are trying to do something like: - setup some OpenGL state. - draw using OpenGL (e.g. glDrawArrays() ) - reset modified OpenGL state. - continue using Cogl to draw They should surround their blocks of raw OpenGL with cogl_begin_gl() and cogl_end_gl(): cogl_begin_gl (); - setup some OpenGL state. - draw using OpenGL (e.g. glDrawArrays() ) - reset modified OpenGL state. cogl_end_gl (); - continue using Cogl to draw Again; we aren't supporting code like this: - setup some OpenGL state. - use Cogl to draw - reset modified OpenGL state. When the internals of Cogl evolves, this is very liable to break. cogl_begin_gl() will flush all internally batched Cogl primitives, and emit all internal Cogl state to OpenGL as if it were going to draw something itself. The result is that the OpenGL modelview matrix will be setup; the state corresponding to the current source material will be setup and other world state such as backface culling, depth and fogging enabledness will be also be sent to OpenGL. Note: no special material state is flushed, so if developers want Cogl to setup a simplified material state it is the their responsibility to set a simple source material before calling cogl_begin_gl. E.g. by calling cogl_set_source_color4ub(). Note: It is the developers responsibility to restore any OpenGL state that they modify to how it was after calling cogl_begin_gl() if they don't do this then the result of further Cogl calls is undefined.
2009-06-29 21:32:05 +00:00
/* Setup the state for the current material */
/* We considered flushing a specific, minimal material here to try and
* simplify the GL state, but decided to avoid special cases and second
* guessing what would be actually helpful.
*
* A user should instead call cogl_set_source_color4ub() before
* cogl_begin_gl() to simplify the state flushed.
*/
options.flags = 0;
_cogl_material_flush_gl_state (ctx->source_material, &options);
/* FIXME: This api is a bit yukky, ideally it will be removed if we
* re-work the cogl_enable mechanism */
enable_flags |= _cogl_material_get_cogl_enable_flags (ctx->source_material);
if (ctx->enable_backface_culling)
enable_flags |= COGL_ENABLE_BACKFACE_CULLING;
cogl_enable (enable_flags);
/* Disable all client texture coordinate arrays */
for (i = 0; i < ctx->n_texcoord_arrays_enabled; i++)
{
GE (glClientActiveTexture (GL_TEXTURE0 + i));
GE (glDisableClientState (GL_TEXTURE_COORD_ARRAY));
}
ctx->n_texcoord_arrays_enabled = 0;
}
void
cogl_end_gl (void)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (!ctx->in_begin_gl_block)
{
static gboolean shown = FALSE;
if (!shown)
g_warning ("cogl_end_gl is being called before cogl_begin_gl");
shown = TRUE;
return;
}
ctx->in_begin_gl_block = FALSE;
}