2008-04-30 15:05:17 +00:00
|
|
|
/*
|
2009-04-27 14:48:12 +00:00
|
|
|
* Cogl
|
2008-04-30 15:05:17 +00:00
|
|
|
*
|
2009-04-27 14:48:12 +00:00
|
|
|
* An object oriented GL/GLES Abstraction/Utility Layer
|
2008-04-30 15:05:17 +00:00
|
|
|
*
|
2009-04-27 14:48:12 +00:00
|
|
|
* Copyright (C) 2007,2008,2009 Intel Corporation.
|
2008-04-30 15:05:17 +00:00
|
|
|
*
|
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* 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 "cogl-internal.h"
|
|
|
|
|
#include "cogl-context.h"
|
2009-03-23 12:29:15 +00:00
|
|
|
#include "cogl-texture-private.h"
|
2009-05-23 16:42:10 +00:00
|
|
|
#include "cogl-material-private.h"
|
2009-06-01 16:10:22 +00:00
|
|
|
#include "cogl-vertex-buffer-private.h"
|
2008-04-30 15:05:17 +00:00
|
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <gmodule.h>
|
2009-01-20 16:20:54 +00:00
|
|
|
#include <math.h>
|
2008-04-30 15:05:17 +00:00
|
|
|
|
|
|
|
|
#define _COGL_MAX_BEZ_RECURSE_DEPTH 16
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
#ifdef 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
|
|
|
#define glGenBuffers ctx->pf_glGenBuffersARB
|
|
|
|
|
#define glBindBuffer ctx->pf_glBindBufferARB
|
|
|
|
|
#define glBufferData ctx->pf_glBufferDataARB
|
|
|
|
|
#define glBufferSubData ctx->pf_glBufferSubDataARB
|
|
|
|
|
#define glDeleteBuffers ctx->pf_glDeleteBuffersARB
|
2009-03-23 12:29:15 +00:00
|
|
|
#define glClientActiveTexture ctx->pf_glClientActiveTexture
|
|
|
|
|
|
[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
|
|
|
#elif defined (HAVE_COGL_GLES2)
|
|
|
|
|
|
|
|
|
|
#include "../gles/cogl-gles2-wrapper.h"
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
#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
|
|
|
|
|
|
|
|
/* XXX NB:
|
|
|
|
|
* Our journal's vertex data is arranged as follows:
|
|
|
|
|
* 4 vertices per quad:
|
2009-06-17 00:31:36 +00:00
|
|
|
* 2 or 3 GLfloats per position (3 when doing software transforms)
|
[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
|
|
|
* 4 RGBA GLubytes,
|
|
|
|
|
* 2 GLfloats per tex coord * n_layers
|
|
|
|
|
*
|
2009-06-10 12:59:45 +00:00
|
|
|
* Where n_layers corresponds to the number of material layers enabled
|
|
|
|
|
*
|
|
|
|
|
* To avoid frequent changes in the stride of our vertex data we always pad
|
|
|
|
|
* n_layers to be >= 2
|
|
|
|
|
*
|
2009-06-17 00:31:36 +00:00
|
|
|
* When we are transforming quads in software we need to also track the z
|
|
|
|
|
* coordinate of transformed vertices.
|
|
|
|
|
*
|
2009-06-10 12:59:45 +00:00
|
|
|
* So for a given number of layers this gets the stride in 32bit words:
|
[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
|
|
|
*/
|
2009-06-17 00:31:36 +00:00
|
|
|
#define SW_TRANSFORM (!(cogl_debug_flags & \
|
|
|
|
|
COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
|
|
|
|
|
#define POS_STRIDE (SW_TRANSFORM ? 3 : 2) /* number of 32bit words */
|
|
|
|
|
#define N_POS_COMPONENTS POS_STRIDE
|
|
|
|
|
#define COLOR_STRIDE 1 /* number of 32bit words */
|
|
|
|
|
#define TEX_STRIDE 2 /* number of 32bit words */
|
|
|
|
|
#define MIN_LAYER_PADING 2
|
[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
|
|
|
#define GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS(N_LAYERS) \
|
2009-06-17 00:31:36 +00:00
|
|
|
(POS_STRIDE + COLOR_STRIDE + \
|
|
|
|
|
TEX_STRIDE * (N_LAYERS < MIN_LAYER_PADING ? MIN_LAYER_PADING : N_LAYERS))
|
[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
|
|
|
|
|
|
|
|
|
|
|
|
|
typedef void (*CoglJournalBatchCallback) (CoglJournalEntry *start,
|
|
|
|
|
int n_entries,
|
|
|
|
|
void *data);
|
|
|
|
|
typedef gboolean (*CoglJournalBatchTest) (CoglJournalEntry *entry0,
|
|
|
|
|
CoglJournalEntry *entry1);
|
2009-08-11 13:17:28 +00:00
|
|
|
typedef CoglVertexBufferIndices CoglJournalIndices;
|
[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
|
|
|
|
|
|
|
|
typedef struct _CoglJournalFlushState
|
|
|
|
|
{
|
2009-06-10 12:59:45 +00:00
|
|
|
size_t stride;
|
[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
|
|
|
/* Note: this is a pointer to handle fallbacks. It normally holds a VBO
|
|
|
|
|
* offset, but when the driver doesn't support VBOs then this points into
|
|
|
|
|
* our GArray of logged vertices. */
|
2009-06-17 00:31:36 +00:00
|
|
|
char * vbo_offset;
|
|
|
|
|
GLuint vertex_offset;
|
[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
|
|
|
#ifndef HAVE_COGL_GL
|
|
|
|
|
CoglJournalIndices *indices;
|
|
|
|
|
size_t indices_type_size;
|
|
|
|
|
#endif
|
|
|
|
|
} CoglJournalFlushState;
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
/* these are defined in the particular backend */
|
2008-12-04 13:45:09 +00:00
|
|
|
void _cogl_path_add_node (gboolean new_sub_path,
|
2009-01-20 16:20:54 +00:00
|
|
|
float x,
|
|
|
|
|
float y);
|
2008-05-05 12:01:19 +00:00
|
|
|
void _cogl_path_fill_nodes ();
|
|
|
|
|
void _cogl_path_stroke_nodes ();
|
Fully integrates CoglMaterial throughout the rest of Cogl
This glues CoglMaterial in as the fundamental way that Cogl describes how to
fill in geometry.
It adds cogl_set_source (), which is used to set the material which will be
used by all subsequent drawing functions
It adds cogl_set_source_texture as a convenience for setting up a default
material with a single texture layer, and cogl_set_source_color is now also
a convenience for setting up a material with a solid fill.
"drawing functions" include, cogl_rectangle, cogl_texture_rectangle,
cogl_texture_multiple_rectangles, cogl_texture_polygon (though the
cogl_texture_* funcs have been renamed; see below for details),
cogl_path_fill/stroke and cogl_vertex_buffer_draw*.
cogl_texture_rectangle, cogl_texture_multiple_rectangles and
cogl_texture_polygon no longer take a texture handle; instead the current
source material is referenced. The functions have also been renamed to:
cogl_rectangle_with_texture_coords, cogl_rectangles_with_texture_coords
and cogl_polygon respectivly.
Most code that previously did:
cogl_texture_rectangle (tex_handle, x, y,...);
needs to be changed to now do:
cogl_set_source_texture (tex_handle);
cogl_rectangle_with_texture_coords (x, y,....);
In the less likely case where you were blending your source texture with a color
like:
cogl_set_source_color4ub (r,g,b,a); /* where r,g,b,a isn't just white */
cogl_texture_rectangle (tex_handle, x, y,...);
you will need your own material to do that:
mat = cogl_material_new ();
cogl_material_set_color4ub (r,g,b,a);
cogl_material_set_layer (mat, 0, tex_handle));
cogl_set_source_material (mat);
Code that uses the texture coordinates, 0, 0, 1, 1 don't need to use
cog_rectangle_with_texure_coords since these are the coordinates that
cogl_rectangle will use.
For cogl_texture_polygon; as well as dropping the texture handle, the
n_vertices and vertices arguments were transposed for consistency. So
code previously written as:
cogl_texture_polygon (tex_handle, 3, verts, TRUE);
need to be written as:
cogl_set_source_texture (tex_handle);
cogl_polygon (verts, 3, TRUE);
All of the unit tests have been updated to now use the material API and
test-cogl-material has been renamed to test-cogl-multitexture since any
textured quad is now technically a test of CoglMaterial but this test
specifically creates a material with multiple texture layers.
Note: The GLES backend has not been updated yet; that will be done in a
following commit.
2009-01-23 16:15:40 +00:00
|
|
|
|
[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_journal_dump_quad_vertices (guint8 *data, int n_layers)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
[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
|
|
|
size_t stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (n_layers);
|
|
|
|
|
int i;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
2009-06-17 00:31:36 +00:00
|
|
|
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);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
[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
|
|
|
for (i = 0; i < 4; i++)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
[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
|
|
|
float *v = (float *)data + (i * stride);
|
2009-06-17 00:31:36 +00:00
|
|
|
guint8 *c = data + (POS_STRIDE * 4) + (i * stride * 4);
|
[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
|
|
|
int j;
|
|
|
|
|
|
2009-06-17 00:31:36 +00:00
|
|
|
if (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM)
|
|
|
|
|
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]);
|
[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
|
|
|
for (j = 0; j < n_layers; j++)
|
|
|
|
|
{
|
2009-06-17 00:31:36 +00:00
|
|
|
float *t = v + POS_STRIDE + COLOR_STRIDE + TEX_STRIDE * j;
|
[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
|
|
|
g_print (", tx%d = %f, ty%d = %f", j, t[0], j, t[1]);
|
|
|
|
|
}
|
|
|
|
|
g_print ("\n");
|
2009-03-23 12:29:15 +00:00
|
|
|
}
|
[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_journal_dump_quad_batch (guint8 *data, int n_layers, int n_quads)
|
|
|
|
|
{
|
|
|
|
|
size_t byte_stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (n_layers) * 4;
|
|
|
|
|
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_dump_quad_vertices (data + byte_stride * 4 * i, n_layers);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
|
for (i = 1; i < n_entries; i++)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
[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
|
|
|
CoglJournalEntry *entry0 = &entries[i - 1];
|
|
|
|
|
CoglJournalEntry *entry1 = entry0 + 1;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
[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
|
|
|
if (can_batch_callback (entry0, entry1))
|
|
|
|
|
{
|
|
|
|
|
batch_len++;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2009-03-23 12:29:15 +00:00
|
|
|
|
[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
|
|
|
batch_callback (batch_start, batch_len, data);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
[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
|
|
|
batch_start = entry1;
|
|
|
|
|
batch_len = 1;
|
|
|
|
|
}
|
2009-03-23 12:29:15 +00:00
|
|
|
|
[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 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)
|
|
|
|
|
{
|
|
|
|
|
CoglJournalFlushState *state = data;
|
|
|
|
|
|
2009-06-17 00:30:24 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
|
2009-06-11 10:54:01 +00:00
|
|
|
g_print ("BATCHING: modelview batch len = %d\n", batch_len);
|
|
|
|
|
|
2009-06-17 00:31:36 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
|
|
|
|
|
GE (glLoadMatrixf ((GLfloat *)&batch_start->model_view));
|
2009-05-28 01:03:16 +00:00
|
|
|
|
2009-06-01 16:10:22 +00:00
|
|
|
#ifdef HAVE_COGL_GL
|
2009-05-28 01:03:16 +00:00
|
|
|
|
[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
|
|
|
GE (glDrawArrays (GL_QUADS, state->vertex_offset, batch_len * 4));
|
2009-06-01 16:10:22 +00:00
|
|
|
|
|
|
|
|
#else /* 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
|
|
|
if (batch_len > 1)
|
|
|
|
|
{
|
|
|
|
|
int indices_offset = (state->vertex_offset / 4) * 6;
|
|
|
|
|
GE (glDrawElements (GL_TRIANGLES,
|
|
|
|
|
6 * batch_len,
|
2009-08-11 13:17:28 +00:00
|
|
|
state->indices->type,
|
|
|
|
|
(GLvoid*)(indices_offset * state->indices_type_size)));
|
[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
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
GE (glDrawArrays (GL_TRIANGLE_FAN,
|
|
|
|
|
state->vertex_offset, /* first */
|
|
|
|
|
4)); /* n vertices */
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
/* DEBUGGING CODE XXX:
|
2009-04-17 14:10:55 +00:00
|
|
|
* This path will cause all rectangles to be drawn with a red, green
|
2009-03-23 12:29:15 +00:00
|
|
|
* or blue outline with no blending. This may e.g. help with debugging
|
|
|
|
|
* texture slicing issues or blending issues, plus it looks quite cool.
|
|
|
|
|
*/
|
2009-04-17 14:10:55 +00:00
|
|
|
if (cogl_debug_flags & COGL_DEBUG_RECTANGLES)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
|
|
|
|
static CoglHandle outline = COGL_INVALID_HANDLE;
|
|
|
|
|
static int color = 0;
|
[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
|
|
|
int i;
|
2009-03-23 12:29:15 +00:00
|
|
|
if (outline == COGL_INVALID_HANDLE)
|
|
|
|
|
outline = cogl_material_new ();
|
|
|
|
|
|
|
|
|
|
cogl_enable (COGL_ENABLE_VERTEX_ARRAY);
|
2009-04-17 14:10:55 +00:00
|
|
|
for (i = 0; i < batch_len; i++, color = (color + 1) % 3)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
|
|
|
|
cogl_material_set_color4ub (outline,
|
|
|
|
|
color == 0 ? 0xff : 0x00,
|
|
|
|
|
color == 1 ? 0xff : 0x00,
|
|
|
|
|
color == 2 ? 0xff : 0x00,
|
|
|
|
|
0xff);
|
2009-05-23 16:42:10 +00:00
|
|
|
_cogl_material_flush_gl_state (outline, NULL);
|
2009-03-23 12:29:15 +00:00
|
|
|
GE( glDrawArrays (GL_LINE_LOOP, 4 * i, 4) );
|
|
|
|
|
}
|
|
|
|
|
}
|
[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
|
|
|
|
|
|
|
|
state->vertex_offset += (4 * batch_len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
|
compare_entry_modelviews (CoglJournalEntry *entry0,
|
|
|
|
|
CoglJournalEntry *entry1)
|
|
|
|
|
{
|
|
|
|
|
/* Batch together quads with the same model view matrix */
|
|
|
|
|
|
|
|
|
|
/* FIXME: this is nasty, there are much nicer ways to track this
|
|
|
|
|
* (at the add_quad_vertices level) without resorting to a memcmp!
|
|
|
|
|
*
|
|
|
|
|
* E.g. If the cogl-current-matrix code maintained an "age" for
|
|
|
|
|
* the modelview matrix we could simply check in add_quad_vertices
|
|
|
|
|
* if the age has increased, and if so record the change as a
|
|
|
|
|
* boolean in the journal.
|
|
|
|
|
*/
|
2009-06-17 00:31:36 +00:00
|
|
|
|
[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
|
|
|
if (memcmp (&entry0->model_view, &entry1->model_view,
|
|
|
|
|
sizeof (GLfloat) * 16) == 0)
|
|
|
|
|
return TRUE;
|
|
|
|
|
else
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* At this point we have a run of quads that we know have compatible
|
|
|
|
|
* materials, but they may not all have the same modelview matrix */
|
|
|
|
|
static void
|
|
|
|
|
_cogl_journal_flush_material_and_entries (CoglJournalEntry *batch_start,
|
|
|
|
|
gint batch_len,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
gulong enable_flags = 0;
|
|
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
2009-06-17 00:30:24 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
|
2009-06-11 10:54:01 +00:00
|
|
|
g_print ("BATCHING: material batch len = %d\n", batch_len);
|
[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_material_flush_gl_state (batch_start->material,
|
|
|
|
|
&batch_start->flush_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 (batch_start->material);
|
|
|
|
|
|
|
|
|
|
if (ctx->enable_backface_culling)
|
|
|
|
|
enable_flags |= COGL_ENABLE_BACKFACE_CULLING;
|
|
|
|
|
|
|
|
|
|
enable_flags |= COGL_ENABLE_VERTEX_ARRAY;
|
|
|
|
|
enable_flags |= COGL_ENABLE_COLOR_ARRAY;
|
|
|
|
|
cogl_enable (enable_flags);
|
|
|
|
|
|
2009-06-17 00:31:36 +00: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... */
|
|
|
|
|
if (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM)
|
|
|
|
|
{
|
|
|
|
|
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);
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
|
compare_entry_materials (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
|
|
|
|
|
{
|
|
|
|
|
/* batch rectangles using compatible materials */
|
|
|
|
|
|
|
|
|
|
/* XXX: _cogl_material_equal may give false negatives since it avoids
|
|
|
|
|
* deep comparisons as an optimization. It aims to compare enough so
|
|
|
|
|
* that we that we are able to batch the 90% common cases, but may not
|
|
|
|
|
* look at less common differences. */
|
|
|
|
|
if (_cogl_material_equal (entry0->material,
|
|
|
|
|
&entry0->flush_options,
|
|
|
|
|
entry1->material,
|
2009-07-03 23:15:49 +00:00
|
|
|
&entry1->flush_options))
|
[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
|
|
|
return TRUE;
|
|
|
|
|
else
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-10 12:59:45 +00:00
|
|
|
/* 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,
|
|
|
|
|
gint batch_len,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
CoglJournalFlushState *state = data;
|
|
|
|
|
int prev_n_texcoord_arrays_enabled;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < batch_start->n_layers; i++)
|
|
|
|
|
{
|
|
|
|
|
GE (glClientActiveTexture (GL_TEXTURE0 + i));
|
|
|
|
|
GE (glEnableClientState (GL_TEXTURE_COORD_ARRAY));
|
|
|
|
|
/* XXX NB:
|
|
|
|
|
* Our journal's vertex data is arranged as follows:
|
|
|
|
|
* 4 vertices per quad:
|
2009-06-17 00:31:36 +00:00
|
|
|
* 2 or 3 GLfloats per position (3 when doing software transforms)
|
2009-06-10 12:59:45 +00:00
|
|
|
* 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)
|
|
|
|
|
*/
|
|
|
|
|
GE (glTexCoordPointer (2, GL_FLOAT, state->stride,
|
2009-06-17 00:31:36 +00:00
|
|
|
(void *)(state->vbo_offset +
|
|
|
|
|
(POS_STRIDE + COLOR_STRIDE) * 4 +
|
|
|
|
|
TEX_STRIDE * 4 * i)));
|
2009-06-10 12:59:45 +00:00
|
|
|
}
|
|
|
|
|
prev_n_texcoord_arrays_enabled =
|
|
|
|
|
ctx->n_texcoord_arrays_enabled;
|
|
|
|
|
ctx->n_texcoord_arrays_enabled = batch_start->n_layers;
|
|
|
|
|
for (; i < prev_n_texcoord_arrays_enabled; i++)
|
|
|
|
|
{
|
|
|
|
|
GE (glClientActiveTexture (GL_TEXTURE0 + i));
|
|
|
|
|
GE (glDisableClientState (GL_TEXTURE_COORD_ARRAY));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
batch_and_call (batch_start,
|
|
|
|
|
batch_len,
|
|
|
|
|
compare_entry_materials,
|
|
|
|
|
_cogl_journal_flush_material_and_entries,
|
|
|
|
|
data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
|
compare_entry_n_layers (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
|
|
|
|
|
{
|
|
|
|
|
if (entry0->n_layers == entry1->n_layers)
|
|
|
|
|
return TRUE;
|
|
|
|
|
else
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
/* 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,
|
|
|
|
|
gint batch_len,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
CoglJournalFlushState *state = data;
|
|
|
|
|
size_t stride;
|
|
|
|
|
#ifndef HAVE_COGL_GL
|
|
|
|
|
int needed_indices = batch_len * 6;
|
|
|
|
|
CoglHandle indices_handle;
|
|
|
|
|
CoglVertexBufferIndices *indices;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
2009-06-17 00:30:24 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
|
2009-06-11 10:54:01 +00:00
|
|
|
g_print ("BATCHING: vbo offset batch len = %d\n", batch_len);
|
|
|
|
|
|
[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
|
|
|
/* XXX NB:
|
2009-06-10 12:59:45 +00:00
|
|
|
* Our journal's vertex data is arranged as follows:
|
|
|
|
|
* 4 vertices per quad:
|
2009-06-17 00:31:36 +00:00
|
|
|
* 2 or 3 GLfloats per position (3 when doing software transforms)
|
2009-06-10 12:59:45 +00:00
|
|
|
* 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)
|
[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
|
|
|
*/
|
|
|
|
|
stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (batch_start->n_layers);
|
|
|
|
|
stride *= sizeof (GLfloat);
|
2009-06-10 12:59:45 +00:00
|
|
|
state->stride = stride;
|
[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
|
|
|
|
2009-06-17 00:31:36 +00:00
|
|
|
GE (glVertexPointer (N_POS_COMPONENTS, GL_FLOAT, stride,
|
|
|
|
|
(void *)state->vbo_offset));
|
[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
|
|
|
GE (glColorPointer (4, GL_UNSIGNED_BYTE, stride,
|
2009-06-17 00:31:36 +00:00
|
|
|
(void *)(state->vbo_offset + (POS_STRIDE * 4))));
|
[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
|
|
|
|
|
|
|
|
#ifndef HAVE_COGL_GL
|
|
|
|
|
indices_handle = cogl_vertex_buffer_indices_get_for_quads (needed_indices);
|
|
|
|
|
indices = _cogl_vertex_buffer_indices_pointer_from_handle (indices_handle);
|
|
|
|
|
state->indices = indices;
|
|
|
|
|
|
|
|
|
|
if (indices->type == GL_UNSIGNED_BYTE)
|
|
|
|
|
state->indices_type_size = 1;
|
|
|
|
|
else if (indices->type == GL_UNSIGNED_SHORT)
|
|
|
|
|
state->indices_type_size = 2;
|
|
|
|
|
else
|
|
|
|
|
g_critical ("unknown indices type %d", indices->type);
|
|
|
|
|
|
|
|
|
|
GE (glBindBuffer (GL_ELEMENT_ARRAY_BUFFER,
|
|
|
|
|
GPOINTER_TO_UINT (indices->vbo_name)));
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* We only call gl{Vertex,Color,Texture}Pointer when the stride within
|
|
|
|
|
* the VBO changes. (due to a change in the number of material layers)
|
|
|
|
|
* While the stride remains constant we walk forward through the above
|
2009-06-11 10:54:01 +00:00
|
|
|
* VBO using a vertex offset passed to glDraw{Arrays,Elements} */
|
[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
|
|
|
state->vertex_offset = 0;
|
|
|
|
|
|
2009-06-17 00:59:28 +00:00
|
|
|
if (cogl_debug_flags & COGL_DEBUG_JOURNAL)
|
|
|
|
|
{
|
|
|
|
|
guint8 *verts;
|
|
|
|
|
|
|
|
|
|
if (cogl_get_features () & COGL_FEATURE_VBOS)
|
|
|
|
|
verts = ((guint8 *)ctx->logged_vertices->data) +
|
|
|
|
|
(size_t)state->vbo_offset;
|
|
|
|
|
else
|
|
|
|
|
verts = (guint8 *)state->vbo_offset;
|
|
|
|
|
_cogl_journal_dump_quad_batch (verts,
|
|
|
|
|
batch_start->n_layers,
|
|
|
|
|
batch_len);
|
|
|
|
|
}
|
[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
|
|
|
|
|
|
|
|
batch_and_call (batch_start,
|
|
|
|
|
batch_len,
|
2009-06-10 12:59:45 +00:00
|
|
|
compare_entry_n_layers,
|
|
|
|
|
_cogl_journal_flush_texcoord_vbo_offsets_and_entries,
|
[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
|
|
|
data);
|
|
|
|
|
|
|
|
|
|
/* progress forward through the VBO containing all our vertices */
|
|
|
|
|
state->vbo_offset += (stride * 4 * batch_len);
|
2009-06-17 00:30:24 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_JOURNAL))
|
2009-06-17 00:59:28 +00:00
|
|
|
g_print ("new vbo offset = %lu\n", (gulong)state->vbo_offset);
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
|
compare_entry_strides (CoglJournalEntry *entry0, CoglJournalEntry *entry1)
|
|
|
|
|
{
|
|
|
|
|
/* Currently the only thing that affects the stride for our vertex arrays
|
|
|
|
|
* is the number of material layers. We need to update our VBO offsets
|
|
|
|
|
* whenever the stride changes. */
|
2009-06-17 00:59:28 +00:00
|
|
|
/* 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. */
|
2009-06-10 12:59:45 +00:00
|
|
|
if (entry0->n_layers == entry1->n_layers ||
|
|
|
|
|
(entry0->n_layers <= MIN_LAYER_PADING &&
|
|
|
|
|
entry1->n_layers <= MIN_LAYER_PADING))
|
[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
|
|
|
return TRUE;
|
|
|
|
|
else
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-17 17:29:03 +00:00
|
|
|
static GLuint
|
[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
|
|
|
upload_vertices_to_vbo (GArray *vertices, CoglJournalFlushState *state)
|
|
|
|
|
{
|
|
|
|
|
size_t needed_vbo_len;
|
2009-09-17 17:29:03 +00:00
|
|
|
GLuint journal_vbo;
|
[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
|
|
|
|
2009-09-17 17:29:03 +00:00
|
|
|
_COGL_GET_CONTEXT (ctx, 0);
|
[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
|
|
|
|
|
|
|
|
needed_vbo_len = vertices->len * sizeof (GLfloat);
|
|
|
|
|
|
2009-06-21 23:11:41 +00:00
|
|
|
g_assert (needed_vbo_len);
|
2009-09-17 17:29:03 +00:00
|
|
|
GE (glGenBuffers (1, &journal_vbo));
|
|
|
|
|
GE (glBindBuffer (GL_ARRAY_BUFFER, journal_vbo));
|
2009-06-21 23:11:41 +00:00
|
|
|
GE (glBufferData (GL_ARRAY_BUFFER,
|
|
|
|
|
needed_vbo_len,
|
|
|
|
|
vertices->data,
|
|
|
|
|
GL_STATIC_DRAW));
|
[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
|
|
|
|
|
|
|
|
/* As we flush the journal entries in batches we walk forward through the
|
|
|
|
|
* above VBO starting at offset 0... */
|
|
|
|
|
state->vbo_offset = 0;
|
2009-09-17 17:29:03 +00:00
|
|
|
|
|
|
|
|
return journal_vbo;
|
2009-03-23 12:29:15 +00:00
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
/* XXX NB: When _cogl_journal_flush() returns all state relating
|
|
|
|
|
* to materials, all glEnable flags and current matrix state
|
|
|
|
|
* is undefined.
|
|
|
|
|
*/
|
2009-03-23 12:29:15 +00:00
|
|
|
void
|
|
|
|
|
_cogl_journal_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
|
|
|
CoglJournalFlushState state;
|
|
|
|
|
int i;
|
2009-09-17 17:29:03 +00:00
|
|
|
GLuint journal_vbo;
|
[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
|
|
|
gboolean vbo_fallback =
|
|
|
|
|
(cogl_get_features () & COGL_FEATURE_VBOS) ? FALSE : TRUE;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
|
|
if (ctx->journal->len == 0)
|
|
|
|
|
return;
|
|
|
|
|
|
2009-06-17 00:30:24 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_BATCHING))
|
2009-06-11 10:54:01 +00:00
|
|
|
g_print ("BATCHING: journal len = %d\n", ctx->journal->len);
|
|
|
|
|
|
[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
|
|
|
/* Load all the vertex data we have accumulated so far into a single VBO
|
|
|
|
|
* to minimize memory management costs within the GL driver. */
|
|
|
|
|
if (!vbo_fallback)
|
2009-09-17 17:29:03 +00:00
|
|
|
journal_vbo = upload_vertices_to_vbo (ctx->logged_vertices, &state);
|
[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
|
|
|
else
|
|
|
|
|
state.vbo_offset = (char *)ctx->logged_vertices->data;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
[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
|
|
|
/* Since the journal deals with emitting the modelview matrices manually
|
2009-07-02 23:34:10 +00:00
|
|
|
* we need to dirty our client side modelview matrix stack cache... */
|
[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_current_matrix_state_dirty ();
|
|
|
|
|
|
2009-07-02 23:34:10 +00:00
|
|
|
/* And explicitly flush other matrix stacks... */
|
|
|
|
|
_cogl_set_current_matrix (COGL_MATRIX_PROJECTION);
|
|
|
|
|
_cogl_current_matrix_state_flush ();
|
|
|
|
|
|
2009-06-17 00:31:36 +00:00
|
|
|
/* If we have transformed all our quads at log time then the whole journal
|
|
|
|
|
* then we ensure no further model transform is applied by loading the
|
|
|
|
|
* identity matrix here...*/
|
|
|
|
|
if (!(cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
|
|
|
|
|
{
|
|
|
|
|
GE (glMatrixMode (GL_MODELVIEW));
|
|
|
|
|
glLoadIdentity ();
|
|
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
/* batch_and_call() batches a list of journal entries according to some
|
|
|
|
|
* given criteria and calls a callback once for each determined batch.
|
2009-03-23 12:29:15 +00:00
|
|
|
*
|
2009-06-17 00:31:36 +00:00
|
|
|
* The process of flushing the journal is staggered to reduce the amount
|
|
|
|
|
* of driver/GPU state changes necessary:
|
|
|
|
|
* 1) We split the entries according to the stride of the vertices:
|
|
|
|
|
* 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
|
|
|
|
|
* is the number of material layers.
|
|
|
|
|
* 2) We split the entries explicitly by the number of material layers:
|
|
|
|
|
* 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.
|
|
|
|
|
* 3) We then split according to compatible Cogl materials:
|
[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
|
|
|
* This is where we flush material state
|
2009-06-17 00:31:36 +00:00
|
|
|
* 4) Finally we split according to modelview matrix changes:
|
[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
|
|
|
* This is when we finally tell GL to draw something.
|
2009-06-17 00:31:36 +00:00
|
|
|
* Note: Splitting by modelview changes is skipped when are doing the
|
|
|
|
|
* vertex transformation in software at log time.
|
2009-03-23 12:29:15 +00:00
|
|
|
*/
|
[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
|
|
|
batch_and_call ((CoglJournalEntry *)ctx->journal->data, /* first entry */
|
|
|
|
|
ctx->journal->len, /* max number of entries to consider */
|
|
|
|
|
compare_entry_strides,
|
|
|
|
|
_cogl_journal_flush_vbo_offsets_and_entries, /* callback */
|
|
|
|
|
&state); /* data */
|
2009-03-23 12:29:15 +00:00
|
|
|
|
[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
|
|
|
for (i = 0; i < ctx->journal->len; i++)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
[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
|
|
|
CoglJournalEntry *entry =
|
|
|
|
|
&g_array_index (ctx->journal, CoglJournalEntry, i);
|
|
|
|
|
_cogl_material_journal_unref (entry->material);
|
2009-03-23 12:29:15 +00:00
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
if (!vbo_fallback)
|
2009-09-17 17:29:03 +00:00
|
|
|
GE (glDeleteBuffers (1, &journal_vbo));
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
g_array_set_size (ctx->journal, 0);
|
|
|
|
|
g_array_set_size (ctx->logged_vertices, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
_cogl_journal_log_quad (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
|
|
|
|
CoglHandle material,
|
[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
|
|
|
int n_layers,
|
|
|
|
|
guint32 fallback_layers,
|
2009-03-23 12:29:15 +00:00
|
|
|
GLuint layer0_override_texture,
|
|
|
|
|
float *tex_coords,
|
|
|
|
|
guint tex_coords_len)
|
|
|
|
|
{
|
[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
|
|
|
size_t stride;
|
|
|
|
|
size_t byte_stride;
|
2009-03-23 12:29:15 +00:00
|
|
|
int next_vert;
|
|
|
|
|
GLfloat *v;
|
[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
|
|
|
GLubyte *c;
|
2009-06-04 13:23:16 +00:00
|
|
|
GLubyte *src_c;
|
2009-03-23 12:29:15 +00:00
|
|
|
int i;
|
|
|
|
|
int next_entry;
|
[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
|
|
|
guint32 disable_layers;
|
2009-03-23 12:29:15 +00:00
|
|
|
CoglJournalEntry *entry;
|
|
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
2009-06-04 13:23:16 +00:00
|
|
|
/* The vertex data is logged into a separate array in a layout that can be
|
2009-03-23 12:29:15 +00:00
|
|
|
* directly passed to OpenGL
|
|
|
|
|
*/
|
|
|
|
|
|
[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
|
|
|
/* XXX: See definition of GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS for details
|
|
|
|
|
* about how we pack our vertex data */
|
|
|
|
|
stride = GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS (n_layers);
|
|
|
|
|
/* NB: stride is in 32bit words */
|
|
|
|
|
byte_stride = stride * 4;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
next_vert = ctx->logged_vertices->len;
|
|
|
|
|
g_array_set_size (ctx->logged_vertices, next_vert + 4 * stride);
|
|
|
|
|
v = &g_array_index (ctx->logged_vertices, GLfloat, next_vert);
|
2009-06-17 00:31:36 +00:00
|
|
|
c = (GLubyte *)(v + POS_STRIDE);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
/* XXX: All the jumping around to fill in this strided buffer doesn't
|
|
|
|
|
* seem ideal. */
|
|
|
|
|
|
|
|
|
|
/* XXX: we could defer expanding the vertex data for GL until we come
|
|
|
|
|
* to flushing the journal. */
|
|
|
|
|
|
2009-06-04 13:23:16 +00:00
|
|
|
/* FIXME: This is a hacky optimization, since it will break if we
|
|
|
|
|
* change the definition of CoglColor: */
|
|
|
|
|
_cogl_material_get_colorubv (material, c);
|
|
|
|
|
src_c = c;
|
|
|
|
|
for (i = 0; i < 3; i++)
|
|
|
|
|
{
|
|
|
|
|
c += byte_stride;
|
|
|
|
|
memcpy (c, src_c, 4);
|
|
|
|
|
}
|
[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
|
|
|
|
2009-06-17 00:31:36 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
|
|
|
|
|
{
|
|
|
|
|
v[0] = x_1; v[1] = y_1;
|
|
|
|
|
v += stride;
|
|
|
|
|
v[0] = x_1; v[1] = y_2;
|
|
|
|
|
v += stride;
|
|
|
|
|
v[0] = x_2; v[1] = y_2;
|
|
|
|
|
v += stride;
|
|
|
|
|
v[0] = x_2; v[1] = y_1;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
CoglMatrix mv;
|
|
|
|
|
float x, y, z, w;
|
|
|
|
|
|
|
|
|
|
cogl_get_modelview_matrix (&mv);
|
|
|
|
|
|
|
|
|
|
x = x_1, y = y_1, z = 0; w = 1;
|
|
|
|
|
cogl_matrix_transform_point (&mv, &x, &y, &z, &w);
|
|
|
|
|
v[0] = x; v[1] = y; v[2] = z;
|
|
|
|
|
v += stride;
|
|
|
|
|
x = x_1, y = y_2, z = 0; w = 1;
|
|
|
|
|
cogl_matrix_transform_point (&mv, &x, &y, &z, &w);
|
|
|
|
|
v[0] = x; v[1] = y; v[2] = z;
|
|
|
|
|
v += stride;
|
|
|
|
|
x = x_2, y = y_2, z = 0; w = 1;
|
|
|
|
|
cogl_matrix_transform_point (&mv, &x, &y, &z, &w);
|
|
|
|
|
v[0] = x; v[1] = y; v[2] = z;
|
|
|
|
|
v += stride;
|
|
|
|
|
x = x_2, y = y_1, z = 0; w = 1;
|
|
|
|
|
cogl_matrix_transform_point (&mv, &x, &y, &z, &w);
|
|
|
|
|
v[0] = x; v[1] = y; v[2] = z;
|
|
|
|
|
}
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
for (i = 0; i < n_layers; i++)
|
|
|
|
|
{
|
2009-06-17 00:31:36 +00:00
|
|
|
/* XXX: See definition of GET_JOURNAL_VB_STRIDE_FOR_N_LAYERS for details
|
|
|
|
|
* about how we pack our vertex data */
|
|
|
|
|
GLfloat *t = &g_array_index (ctx->logged_vertices, GLfloat,
|
|
|
|
|
next_vert + POS_STRIDE +
|
|
|
|
|
COLOR_STRIDE + TEX_STRIDE * i);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
t[0] = tex_coords[0]; t[1] = tex_coords[1];
|
|
|
|
|
t += stride;
|
|
|
|
|
t[0] = tex_coords[0]; t[1] = tex_coords[3];
|
|
|
|
|
t += stride;
|
|
|
|
|
t[0] = tex_coords[2]; t[1] = tex_coords[3];
|
|
|
|
|
t += stride;
|
|
|
|
|
t[0] = tex_coords[2]; t[1] = tex_coords[1];
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-17 00:30:24 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_JOURNAL))
|
2009-06-17 00:59:28 +00:00
|
|
|
{
|
|
|
|
|
g_print ("Logged new quad:\n");
|
|
|
|
|
v = &g_array_index (ctx->logged_vertices, GLfloat, next_vert);
|
|
|
|
|
_cogl_journal_dump_quad_vertices ((guint8 *)v, n_layers);
|
|
|
|
|
}
|
[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
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
next_entry = ctx->journal->len;
|
|
|
|
|
g_array_set_size (ctx->journal, next_entry + 1);
|
|
|
|
|
entry = &g_array_index (ctx->journal, CoglJournalEntry, next_entry);
|
|
|
|
|
|
[cogl] 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
|
|
|
disable_layers = (1 << n_layers) - 1;
|
|
|
|
|
disable_layers = ~disable_layers;
|
|
|
|
|
|
|
|
|
|
entry->material = _cogl_material_journal_ref (material);
|
2009-03-23 12:29:15 +00:00
|
|
|
entry->n_layers = n_layers;
|
[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
|
|
|
entry->flush_options.flags =
|
|
|
|
|
COGL_MATERIAL_FLUSH_FALLBACK_MASK |
|
|
|
|
|
COGL_MATERIAL_FLUSH_DISABLE_MASK |
|
|
|
|
|
COGL_MATERIAL_FLUSH_SKIP_GL_COLOR;
|
|
|
|
|
entry->flush_options.fallback_layers = fallback_layers;
|
|
|
|
|
entry->flush_options.disable_layers = disable_layers;
|
2009-07-07 15:16:56 +00:00
|
|
|
if (layer0_override_texture)
|
|
|
|
|
{
|
|
|
|
|
entry->flush_options.flags |= COGL_MATERIAL_FLUSH_LAYER0_OVERRIDE;
|
|
|
|
|
entry->flush_options.layer0_override_texture = layer0_override_texture;
|
|
|
|
|
}
|
2009-06-17 00:31:36 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_SOFTWARE_TRANSFORM))
|
|
|
|
|
cogl_get_modelview_matrix (&entry->model_view);
|
[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
|
|
|
|
2009-06-17 00:30:24 +00:00
|
|
|
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_DISABLE_BATCHING
|
|
|
|
|
|| cogl_debug_flags & COGL_DEBUG_RECTANGLES))
|
[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 ();
|
2009-03-23 12:29:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
_cogl_texture_sliced_quad (CoglTexture *tex,
|
|
|
|
|
CoglHandle material,
|
|
|
|
|
float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
|
|
|
|
float tx_1,
|
|
|
|
|
float ty_1,
|
|
|
|
|
float tx_2,
|
|
|
|
|
float ty_2)
|
|
|
|
|
{
|
|
|
|
|
CoglSpanIter iter_x , iter_y;
|
|
|
|
|
float tw , th;
|
|
|
|
|
float tqx , tqy;
|
|
|
|
|
float first_tx , first_ty;
|
|
|
|
|
float first_qx , first_qy;
|
|
|
|
|
float slice_tx1 , slice_ty1;
|
|
|
|
|
float slice_tx2 , slice_ty2;
|
|
|
|
|
float slice_qx1 , slice_qy1;
|
|
|
|
|
float slice_qx2 , slice_qy2;
|
|
|
|
|
GLuint gl_handle;
|
|
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
2009-05-19 13:44:29 +00:00
|
|
|
COGL_NOTE (DRAW, "Drawing Tex Quad (Sliced Mode)");
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
/* We can't use hardware repeat so we need to set clamp to edge
|
|
|
|
|
otherwise it might pull in edge pixels from the other side */
|
|
|
|
|
_cogl_texture_set_wrap_mode_parameter (tex, GL_CLAMP_TO_EDGE);
|
|
|
|
|
|
|
|
|
|
/* If the texture coordinates are backwards then swap both the
|
|
|
|
|
geometry and texture coordinates so that the texture will be
|
|
|
|
|
flipped but we can still use the same algorithm to iterate the
|
|
|
|
|
slices */
|
|
|
|
|
if (tx_2 < tx_1)
|
|
|
|
|
{
|
|
|
|
|
float temp = x_1;
|
|
|
|
|
x_1 = x_2;
|
|
|
|
|
x_2 = temp;
|
|
|
|
|
temp = tx_1;
|
|
|
|
|
tx_1 = tx_2;
|
|
|
|
|
tx_2 = temp;
|
|
|
|
|
}
|
|
|
|
|
if (ty_2 < ty_1)
|
|
|
|
|
{
|
|
|
|
|
float temp = y_1;
|
|
|
|
|
y_1 = y_2;
|
|
|
|
|
y_2 = temp;
|
|
|
|
|
temp = ty_1;
|
|
|
|
|
ty_1 = ty_2;
|
|
|
|
|
ty_2 = temp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Scale ratio from texture to quad widths */
|
|
|
|
|
tw = (float)(tex->bitmap.width);
|
|
|
|
|
th = (float)(tex->bitmap.height);
|
|
|
|
|
|
|
|
|
|
tqx = (x_2 - x_1) / (tw * (tx_2 - tx_1));
|
|
|
|
|
tqy = (y_2 - y_1) / (th * (ty_2 - ty_1));
|
|
|
|
|
|
|
|
|
|
/* Integral texture coordinate for first tile */
|
|
|
|
|
first_tx = (float)(floorf (tx_1));
|
|
|
|
|
first_ty = (float)(floorf (ty_1));
|
|
|
|
|
|
|
|
|
|
/* Denormalize texture coordinates */
|
|
|
|
|
first_tx = (first_tx * tw);
|
|
|
|
|
first_ty = (first_ty * th);
|
|
|
|
|
tx_1 = (tx_1 * tw);
|
|
|
|
|
ty_1 = (ty_1 * th);
|
|
|
|
|
tx_2 = (tx_2 * tw);
|
|
|
|
|
ty_2 = (ty_2 * th);
|
|
|
|
|
|
|
|
|
|
/* Quad coordinate of the first tile */
|
|
|
|
|
first_qx = x_1 - (tx_1 - first_tx) * tqx;
|
|
|
|
|
first_qy = y_1 - (ty_1 - first_ty) * tqy;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Iterate until whole quad height covered */
|
|
|
|
|
for (_cogl_span_iter_begin (&iter_y, tex->slice_y_spans,
|
|
|
|
|
first_ty, ty_1, ty_2) ;
|
|
|
|
|
!_cogl_span_iter_end (&iter_y) ;
|
|
|
|
|
_cogl_span_iter_next (&iter_y) )
|
|
|
|
|
{
|
|
|
|
|
float tex_coords[4];
|
|
|
|
|
|
|
|
|
|
/* Discard slices out of quad early */
|
|
|
|
|
if (!iter_y.intersects) continue;
|
|
|
|
|
|
|
|
|
|
/* Span-quad intersection in quad coordinates */
|
|
|
|
|
slice_qy1 = first_qy + (iter_y.intersect_start - first_ty) * tqy;
|
|
|
|
|
|
|
|
|
|
slice_qy2 = first_qy + (iter_y.intersect_end - first_ty) * tqy;
|
|
|
|
|
|
|
|
|
|
/* Localize slice texture coordinates */
|
|
|
|
|
slice_ty1 = iter_y.intersect_start - iter_y.pos;
|
|
|
|
|
slice_ty2 = iter_y.intersect_end - iter_y.pos;
|
|
|
|
|
|
|
|
|
|
/* Normalize texture coordinates to current slice
|
|
|
|
|
(rectangle texture targets take denormalized) */
|
|
|
|
|
#if HAVE_COGL_GL
|
|
|
|
|
if (tex->gl_target != CGL_TEXTURE_RECTANGLE_ARB)
|
|
|
|
|
#endif
|
|
|
|
|
{
|
|
|
|
|
slice_ty1 /= iter_y.span->size;
|
|
|
|
|
slice_ty2 /= iter_y.span->size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Iterate until whole quad width covered */
|
|
|
|
|
for (_cogl_span_iter_begin (&iter_x, tex->slice_x_spans,
|
|
|
|
|
first_tx, tx_1, tx_2) ;
|
|
|
|
|
!_cogl_span_iter_end (&iter_x) ;
|
|
|
|
|
_cogl_span_iter_next (&iter_x) )
|
|
|
|
|
{
|
|
|
|
|
/* Discard slices out of quad early */
|
|
|
|
|
if (!iter_x.intersects) continue;
|
|
|
|
|
|
|
|
|
|
/* Span-quad intersection in quad coordinates */
|
|
|
|
|
slice_qx1 = first_qx + (iter_x.intersect_start - first_tx) * tqx;
|
|
|
|
|
|
|
|
|
|
slice_qx2 = first_qx + (iter_x.intersect_end - first_tx) * tqx;
|
|
|
|
|
|
|
|
|
|
/* Localize slice texture coordinates */
|
|
|
|
|
slice_tx1 = iter_x.intersect_start - iter_x.pos;
|
|
|
|
|
slice_tx2 = iter_x.intersect_end - iter_x.pos;
|
|
|
|
|
|
|
|
|
|
/* Normalize texture coordinates to current slice
|
|
|
|
|
(rectangle texture targets take denormalized) */
|
|
|
|
|
#if HAVE_COGL_GL
|
|
|
|
|
if (tex->gl_target != CGL_TEXTURE_RECTANGLE_ARB)
|
|
|
|
|
#endif
|
|
|
|
|
{
|
|
|
|
|
slice_tx1 /= iter_x.span->size;
|
|
|
|
|
slice_tx2 /= iter_x.span->size;
|
|
|
|
|
}
|
|
|
|
|
|
2009-05-19 13:44:29 +00:00
|
|
|
COGL_NOTE (DRAW,
|
|
|
|
|
"~~~~~ slice (%d, %d)\n"
|
|
|
|
|
"qx1: %f\t"
|
|
|
|
|
"qy1: %f\n"
|
|
|
|
|
"qx2: %f\t"
|
|
|
|
|
"qy2: %f\n"
|
|
|
|
|
"tx1: %f\t"
|
|
|
|
|
"ty1: %f\n"
|
|
|
|
|
"tx2: %f\t"
|
|
|
|
|
"ty2: %f\n",
|
|
|
|
|
iter_x.index, iter_y.index,
|
|
|
|
|
slice_qx1, slice_qy1,
|
|
|
|
|
slice_qx2, slice_qy2,
|
|
|
|
|
slice_tx1, slice_ty1,
|
|
|
|
|
slice_tx2, slice_ty2);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
/* Pick and bind opengl texture object */
|
|
|
|
|
gl_handle = g_array_index (tex->slice_gl_handles, GLuint,
|
|
|
|
|
iter_y.index * iter_x.array->len +
|
|
|
|
|
iter_x.index);
|
|
|
|
|
|
|
|
|
|
tex_coords[0] = slice_tx1;
|
|
|
|
|
tex_coords[1] = slice_ty1;
|
|
|
|
|
tex_coords[2] = slice_tx2;
|
|
|
|
|
tex_coords[3] = slice_ty2;
|
|
|
|
|
_cogl_journal_log_quad (slice_qx1,
|
|
|
|
|
slice_qy1,
|
|
|
|
|
slice_qx2,
|
|
|
|
|
slice_qy2,
|
|
|
|
|
material,
|
|
|
|
|
1, /* one layer */
|
|
|
|
|
0, /* don't need to use fallbacks */
|
|
|
|
|
gl_handle, /* replace the layer0 texture */
|
|
|
|
|
tex_coords,
|
|
|
|
|
4);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
|
_cogl_multitexture_unsliced_quad (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
|
|
|
|
CoglHandle material,
|
[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
|
|
|
guint32 fallback_layers,
|
2009-03-23 12:29:15 +00:00
|
|
|
const float *user_tex_coords,
|
|
|
|
|
gint user_tex_coords_len)
|
|
|
|
|
{
|
[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
|
|
|
int n_layers = cogl_material_get_n_layers (material);
|
|
|
|
|
float *final_tex_coords = alloca (sizeof (float) * 4 * n_layers);
|
2009-03-23 12:29:15 +00:00
|
|
|
const GList *layers;
|
|
|
|
|
GList *tmp;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, FALSE);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Validate the texture coordinates for this rectangle.
|
|
|
|
|
*/
|
|
|
|
|
layers = cogl_material_get_layers (material);
|
|
|
|
|
for (tmp = (GList *)layers, i = 0; tmp != NULL; tmp = tmp->next, i++)
|
|
|
|
|
{
|
|
|
|
|
CoglHandle layer = (CoglHandle)tmp->data;
|
|
|
|
|
CoglHandle tex_handle;
|
|
|
|
|
CoglTexture *tex;
|
|
|
|
|
const float *in_tex_coords;
|
|
|
|
|
float *out_tex_coords;
|
|
|
|
|
CoglTexSliceSpan *x_span;
|
|
|
|
|
CoglTexSliceSpan *y_span;
|
|
|
|
|
|
2009-06-19 11:15:12 +00:00
|
|
|
tex_handle = cogl_material_layer_get_texture (layer);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
2009-06-19 11:15:12 +00:00
|
|
|
/* COGL_INVALID_HANDLE textures are handled by
|
|
|
|
|
* _cogl_material_flush_gl_state */
|
|
|
|
|
if (tex_handle == COGL_INVALID_HANDLE)
|
|
|
|
|
continue;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
tex = _cogl_texture_pointer_from_handle (tex_handle);
|
|
|
|
|
|
|
|
|
|
in_tex_coords = &user_tex_coords[i * 4];
|
|
|
|
|
out_tex_coords = &final_tex_coords[i * 4];
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* If the texture has waste or we are using GL_TEXTURE_RECT we
|
|
|
|
|
* can't handle texture repeating so we check that the texture
|
|
|
|
|
* coords lie in the range [0,1].
|
|
|
|
|
*
|
|
|
|
|
* NB: We already know that no texture matrix is being used
|
|
|
|
|
* if the texture has waste since we validated that early on.
|
|
|
|
|
* TODO: check for a texture matrix in the GL_TEXTURE_RECT
|
|
|
|
|
* case.
|
|
|
|
|
*/
|
|
|
|
|
if ((
|
|
|
|
|
#if HAVE_COGL_GL
|
|
|
|
|
tex->gl_target == GL_TEXTURE_RECTANGLE_ARB ||
|
|
|
|
|
#endif
|
|
|
|
|
_cogl_texture_span_has_waste (tex, 0, 0))
|
|
|
|
|
&& i < user_tex_coords_len / 4
|
|
|
|
|
&& (in_tex_coords[0] < 0 || in_tex_coords[0] > 1.0
|
|
|
|
|
|| in_tex_coords[1] < 0 || in_tex_coords[1] > 1.0
|
|
|
|
|
|| in_tex_coords[2] < 0 || in_tex_coords[2] > 1.0
|
|
|
|
|
|| in_tex_coords[3] < 0 || in_tex_coords[3] > 1.0))
|
|
|
|
|
{
|
|
|
|
|
if (i == 0)
|
|
|
|
|
{
|
|
|
|
|
if (n_layers > 1)
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
g_warning ("Skipping layers 1..n of your material since "
|
|
|
|
|
"the first layer has waste and you supplied "
|
|
|
|
|
"texture coordinates outside the range [0,1]. "
|
|
|
|
|
"We don't currently support any "
|
|
|
|
|
"multi-texturing using textures with waste "
|
|
|
|
|
"when repeating is necissary so we are "
|
|
|
|
|
"falling back to sliced textures assuming "
|
|
|
|
|
"layer 0 is the most important one keep");
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
}
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
g_warning ("Skipping layer %d of your material "
|
|
|
|
|
"consisting of a texture with waste since "
|
|
|
|
|
"you have supplied texture coords outside "
|
|
|
|
|
"the range [0,1] (unsupported when "
|
|
|
|
|
"multi-texturing)", i);
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
|
|
|
|
|
/* NB: marking for fallback will replace the layer with
|
|
|
|
|
* a default transparent texture */
|
[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
|
|
|
fallback_layers |= (1 << i);
|
2009-03-23 12:29:15 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Setup the texture unit...
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* NB: The user might not have supplied texture coordinates for all
|
|
|
|
|
* layers... */
|
|
|
|
|
if (i < (user_tex_coords_len / 4))
|
|
|
|
|
{
|
|
|
|
|
GLenum wrap_mode;
|
|
|
|
|
|
|
|
|
|
/* If the texture coords are all in the range [0,1] then we want to
|
|
|
|
|
clamp the coords to the edge otherwise it can pull in edge pixels
|
|
|
|
|
from the wrong side when scaled */
|
|
|
|
|
if (in_tex_coords[0] >= 0 && in_tex_coords[0] <= 1.0
|
|
|
|
|
&& in_tex_coords[1] >= 0 && in_tex_coords[1] <= 1.0
|
|
|
|
|
&& in_tex_coords[2] >= 0 && in_tex_coords[2] <= 1.0
|
|
|
|
|
&& in_tex_coords[3] >= 0 && in_tex_coords[3] <= 1.0)
|
|
|
|
|
wrap_mode = GL_CLAMP_TO_EDGE;
|
|
|
|
|
else
|
|
|
|
|
wrap_mode = GL_REPEAT;
|
|
|
|
|
|
|
|
|
|
memcpy (out_tex_coords, in_tex_coords, sizeof (GLfloat) * 4);
|
|
|
|
|
|
|
|
|
|
_cogl_texture_set_wrap_mode_parameter (tex, wrap_mode);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
out_tex_coords[0] = 0; /* tx_1 */
|
|
|
|
|
out_tex_coords[1] = 0; /* ty_1 */
|
|
|
|
|
out_tex_coords[2] = 1.0; /* tx_2 */
|
|
|
|
|
out_tex_coords[3] = 1.0; /* ty_2 */
|
|
|
|
|
|
|
|
|
|
_cogl_texture_set_wrap_mode_parameter (tex, GL_CLAMP_TO_EDGE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Don't include the waste in the texture coordinates */
|
|
|
|
|
x_span = &g_array_index (tex->slice_x_spans, CoglTexSliceSpan, 0);
|
|
|
|
|
y_span = &g_array_index (tex->slice_y_spans, CoglTexSliceSpan, 0);
|
|
|
|
|
|
|
|
|
|
out_tex_coords[0] =
|
|
|
|
|
out_tex_coords[0] * (x_span->size - x_span->waste) / x_span->size;
|
|
|
|
|
out_tex_coords[1] =
|
|
|
|
|
out_tex_coords[1] * (y_span->size - y_span->waste) / y_span->size;
|
|
|
|
|
out_tex_coords[2] =
|
|
|
|
|
out_tex_coords[2] * (x_span->size - x_span->waste) / x_span->size;
|
|
|
|
|
out_tex_coords[3] =
|
|
|
|
|
out_tex_coords[3] * (y_span->size - y_span->waste) / y_span->size;
|
|
|
|
|
|
|
|
|
|
#if HAVE_COGL_GL
|
|
|
|
|
/* Denormalize texture coordinates for rectangle textures */
|
|
|
|
|
if (tex->gl_target == GL_TEXTURE_RECTANGLE_ARB)
|
|
|
|
|
{
|
|
|
|
|
out_tex_coords[0] *= x_span->size;
|
|
|
|
|
out_tex_coords[1] *= y_span->size;
|
|
|
|
|
out_tex_coords[2] *= x_span->size;
|
|
|
|
|
out_tex_coords[3] *= y_span->size;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
_cogl_journal_log_quad (x_1,
|
|
|
|
|
y_1,
|
|
|
|
|
x_2,
|
|
|
|
|
y_2,
|
|
|
|
|
material,
|
|
|
|
|
n_layers,
|
[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
|
|
|
fallback_layers,
|
2009-03-23 12:29:15 +00:00
|
|
|
0, /* don't replace the layer0 texture */
|
|
|
|
|
final_tex_coords,
|
|
|
|
|
n_layers * 4);
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct _CoglMutiTexturedRect
|
|
|
|
|
{
|
|
|
|
|
float x_1;
|
|
|
|
|
float y_1;
|
|
|
|
|
float x_2;
|
|
|
|
|
float y_2;
|
|
|
|
|
const float *tex_coords;
|
|
|
|
|
gint tex_coords_len;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
_cogl_rectangles_with_multitexture_coords (
|
|
|
|
|
struct _CoglMutiTexturedRect *rects,
|
|
|
|
|
gint n_rects)
|
|
|
|
|
{
|
|
|
|
|
CoglHandle material;
|
|
|
|
|
const GList *layers;
|
|
|
|
|
int n_layers;
|
|
|
|
|
const GList *tmp;
|
[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
|
|
|
guint32 fallback_layers = 0;
|
2009-03-23 12:29:15 +00:00
|
|
|
gboolean all_use_sliced_quad_fallback = FALSE;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
|
|
cogl_clip_ensure ();
|
|
|
|
|
|
|
|
|
|
material = ctx->source_material;
|
|
|
|
|
|
|
|
|
|
layers = cogl_material_get_layers (material);
|
[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
|
|
|
n_layers = cogl_material_get_n_layers (material);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Validate all the layers of the current source material...
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
for (tmp = layers, i = 0; tmp != NULL; tmp = tmp->next, i++)
|
|
|
|
|
{
|
|
|
|
|
CoglHandle layer = tmp->data;
|
2009-06-19 11:15:12 +00:00
|
|
|
CoglHandle tex_handle;
|
|
|
|
|
CoglTexture *texture = NULL;
|
2009-03-23 12:29:15 +00:00
|
|
|
gulong flags;
|
|
|
|
|
|
|
|
|
|
if (cogl_material_layer_get_type (layer)
|
|
|
|
|
!= COGL_MATERIAL_LAYER_TYPE_TEXTURE)
|
|
|
|
|
continue;
|
|
|
|
|
|
2009-06-19 11:15:12 +00:00
|
|
|
tex_handle = cogl_material_layer_get_texture (layer);
|
|
|
|
|
|
|
|
|
|
/* COGL_INVALID_HANDLE textures are handled by
|
|
|
|
|
* _cogl_material_flush_gl_state */
|
|
|
|
|
if (tex_handle == COGL_INVALID_HANDLE)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
texture = _cogl_texture_pointer_from_handle (tex_handle);
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
/* XXX:
|
|
|
|
|
* For now, if the first layer is sliced then all other layers are
|
|
|
|
|
* ignored since we currently don't support multi-texturing with
|
|
|
|
|
* sliced textures. If the first layer is not sliced then any other
|
|
|
|
|
* layers found to be sliced will be skipped. (with a warning)
|
|
|
|
|
*
|
|
|
|
|
* TODO: Add support for multi-texturing rectangles with sliced
|
|
|
|
|
* textures if no texture matrices are in use.
|
|
|
|
|
*/
|
|
|
|
|
if (cogl_texture_is_sliced (tex_handle))
|
|
|
|
|
{
|
|
|
|
|
if (i == 0)
|
|
|
|
|
{
|
[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
|
|
|
fallback_layers = ~1; /* fallback all except the first layer */
|
2009-03-23 12:29:15 +00:00
|
|
|
all_use_sliced_quad_fallback = TRUE;
|
|
|
|
|
if (tmp->next)
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
g_warning ("Skipping layers 1..n of your material since "
|
|
|
|
|
"the first layer is sliced. We don't currently "
|
|
|
|
|
"support any multi-texturing with sliced "
|
|
|
|
|
"textures but assume layer 0 is the most "
|
|
|
|
|
"important to keep");
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
g_warning ("Skipping layer %d of your material consisting of "
|
|
|
|
|
"a sliced texture (unsuported for multi texturing)",
|
|
|
|
|
i);
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
|
|
|
|
|
/* NB: marking for fallback will replace the layer with
|
|
|
|
|
* a default transparent texture */
|
[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
|
|
|
fallback_layers |= (1 << i);
|
2009-03-23 12:29:15 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We don't support multi texturing using textures with any waste if the
|
|
|
|
|
* user has supplied a custom texture matrix, since we don't know if
|
|
|
|
|
* the result will end up trying to texture from the waste area. */
|
2009-05-23 16:42:10 +00:00
|
|
|
flags = _cogl_material_layer_get_flags (layer);
|
2009-03-23 12:29:15 +00:00
|
|
|
if (flags & COGL_MATERIAL_LAYER_FLAG_HAS_USER_MATRIX
|
|
|
|
|
&& _cogl_texture_span_has_waste (texture, 0, 0))
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
g_warning ("Skipping layer %d of your material consisting of a "
|
|
|
|
|
"texture with waste since you have supplied a custom "
|
|
|
|
|
"texture matrix and the result may try to sample from "
|
|
|
|
|
"the waste area of your texture.", i);
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
|
|
|
|
|
/* NB: marking for fallback will replace the layer with
|
|
|
|
|
* a default transparent texture */
|
[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
|
|
|
fallback_layers |= (1 << i);
|
2009-03-23 12:29:15 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Emit geometry for each of the rectangles...
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < n_rects; i++)
|
|
|
|
|
{
|
|
|
|
|
if (all_use_sliced_quad_fallback
|
|
|
|
|
|| !_cogl_multitexture_unsliced_quad (rects[i].x_1, rects[i].y_1,
|
|
|
|
|
rects[i].x_2, rects[i].y_2,
|
|
|
|
|
material,
|
[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
|
|
|
fallback_layers,
|
2009-03-23 12:29:15 +00:00
|
|
|
rects[i].tex_coords,
|
|
|
|
|
rects[i].tex_coords_len))
|
|
|
|
|
{
|
|
|
|
|
CoglHandle first_layer, tex_handle;
|
|
|
|
|
CoglTexture *texture;
|
|
|
|
|
|
|
|
|
|
first_layer = layers->data;
|
|
|
|
|
tex_handle = cogl_material_layer_get_texture (first_layer);
|
|
|
|
|
texture = _cogl_texture_pointer_from_handle (tex_handle);
|
|
|
|
|
if (rects[i].tex_coords)
|
|
|
|
|
_cogl_texture_sliced_quad (texture,
|
|
|
|
|
material,
|
|
|
|
|
rects[i].x_1, rects[i].y_1,
|
|
|
|
|
rects[i].x_2, rects[i].y_2,
|
|
|
|
|
rects[i].tex_coords[0],
|
|
|
|
|
rects[i].tex_coords[1],
|
|
|
|
|
rects[i].tex_coords[2],
|
|
|
|
|
rects[i].tex_coords[3]);
|
|
|
|
|
else
|
|
|
|
|
_cogl_texture_sliced_quad (texture,
|
|
|
|
|
material,
|
|
|
|
|
rects[i].x_1, rects[i].y_1,
|
|
|
|
|
rects[i].x_2, rects[i].y_2,
|
|
|
|
|
0.0f, 0.0f, 1.0f, 1.0f);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
#if 0
|
|
|
|
|
/* XXX: The current journal doesn't handle changes to the model view matrix
|
|
|
|
|
* so for now we force a flush at the end of every primitive. */
|
2009-03-23 12:29:15 +00:00
|
|
|
_cogl_journal_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
|
|
|
#endif
|
2009-03-23 12:29:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_rectangles (const float *verts,
|
|
|
|
|
guint n_rects)
|
|
|
|
|
{
|
2009-06-16 20:29:21 +00:00
|
|
|
struct _CoglMutiTexturedRect *rects;
|
2009-03-23 12:29:15 +00:00
|
|
|
int i;
|
|
|
|
|
|
2009-06-16 20:29:21 +00:00
|
|
|
rects = g_alloca (n_rects * sizeof (struct _CoglMutiTexturedRect));
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
for (i = 0; i < n_rects; i++)
|
|
|
|
|
{
|
|
|
|
|
rects[i].x_1 = verts[i * 4];
|
|
|
|
|
rects[i].y_1 = verts[i * 4 + 1];
|
|
|
|
|
rects[i].x_2 = verts[i * 4 + 2];
|
|
|
|
|
rects[i].y_2 = verts[i * 4 + 3];
|
|
|
|
|
rects[i].tex_coords = NULL;
|
|
|
|
|
rects[i].tex_coords_len = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
_cogl_rectangles_with_multitexture_coords (rects, n_rects);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_rectangles_with_texture_coords (const float *verts,
|
|
|
|
|
guint n_rects)
|
|
|
|
|
{
|
2009-06-16 20:29:21 +00:00
|
|
|
struct _CoglMutiTexturedRect *rects;
|
2009-03-23 12:29:15 +00:00
|
|
|
int i;
|
|
|
|
|
|
2009-06-16 20:29:21 +00:00
|
|
|
rects = g_alloca (n_rects * sizeof (struct _CoglMutiTexturedRect));
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
for (i = 0; i < n_rects; i++)
|
|
|
|
|
{
|
|
|
|
|
rects[i].x_1 = verts[i * 8];
|
|
|
|
|
rects[i].y_1 = verts[i * 8 + 1];
|
|
|
|
|
rects[i].x_2 = verts[i * 8 + 2];
|
|
|
|
|
rects[i].y_2 = verts[i * 8 + 3];
|
|
|
|
|
/* FIXME: rect should be defined to have a const float *geom;
|
|
|
|
|
* instead, to avoid this copy
|
|
|
|
|
* rect[i].geom = &verts[n_rects * 8]; */
|
|
|
|
|
rects[i].tex_coords = &verts[i * 8 + 4];
|
|
|
|
|
rects[i].tex_coords_len = 4;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
_cogl_rectangles_with_multitexture_coords (rects, n_rects);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_rectangle_with_texture_coords (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
|
|
|
|
float tx_1,
|
|
|
|
|
float ty_1,
|
|
|
|
|
float tx_2,
|
|
|
|
|
float ty_2)
|
|
|
|
|
{
|
|
|
|
|
float verts[8];
|
|
|
|
|
|
|
|
|
|
verts[0] = x_1;
|
|
|
|
|
verts[1] = y_1;
|
|
|
|
|
verts[2] = x_2;
|
|
|
|
|
verts[3] = y_2;
|
|
|
|
|
verts[4] = tx_1;
|
|
|
|
|
verts[5] = ty_1;
|
|
|
|
|
verts[6] = tx_2;
|
|
|
|
|
verts[7] = ty_2;
|
|
|
|
|
|
|
|
|
|
cogl_rectangles_with_texture_coords (verts, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_rectangle_with_multitexture_coords (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
|
|
|
|
const float *user_tex_coords,
|
|
|
|
|
gint user_tex_coords_len)
|
|
|
|
|
{
|
|
|
|
|
struct _CoglMutiTexturedRect rect;
|
|
|
|
|
|
|
|
|
|
rect.x_1 = x_1;
|
|
|
|
|
rect.y_1 = y_1;
|
|
|
|
|
rect.x_2 = x_2;
|
|
|
|
|
rect.y_2 = y_2;
|
|
|
|
|
rect.tex_coords = user_tex_coords;
|
|
|
|
|
rect.tex_coords_len = user_tex_coords_len;
|
|
|
|
|
|
|
|
|
|
_cogl_rectangles_with_multitexture_coords (&rect, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2008-05-05 12:01:19 +00:00
|
|
|
void
|
2009-01-29 13:31:11 +00:00
|
|
|
cogl_rectangle (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2)
|
2008-05-05 12:01:19 +00:00
|
|
|
{
|
2009-01-29 13:31:11 +00:00
|
|
|
cogl_rectangle_with_multitexture_coords (x_1, y_1,
|
|
|
|
|
x_2, y_2,
|
|
|
|
|
NULL, 0);
|
2008-05-05 12:01:19 +00:00
|
|
|
}
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
static void
|
|
|
|
|
_cogl_texture_sliced_polygon (CoglTextureVertex *vertices,
|
|
|
|
|
guint n_vertices,
|
|
|
|
|
guint stride,
|
|
|
|
|
gboolean use_color)
|
|
|
|
|
{
|
|
|
|
|
const GList *layers;
|
|
|
|
|
CoglHandle layer0;
|
|
|
|
|
CoglHandle tex_handle;
|
|
|
|
|
CoglTexture *tex;
|
|
|
|
|
CoglTexSliceSpan *y_span, *x_span;
|
|
|
|
|
int x, y, tex_num, i;
|
|
|
|
|
GLuint gl_handle;
|
|
|
|
|
GLfloat *v;
|
[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
|
|
|
CoglMaterialFlushOptions options;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
|
|
/* We can assume in this case that we have at least one layer in the
|
|
|
|
|
* material that corresponds to a sliced cogl texture */
|
|
|
|
|
layers = cogl_material_get_layers (ctx->source_material);
|
|
|
|
|
layer0 = (CoglHandle)layers->data;
|
|
|
|
|
tex_handle = cogl_material_layer_get_texture (layer0);
|
|
|
|
|
tex = _cogl_texture_pointer_from_handle (tex_handle);
|
|
|
|
|
|
|
|
|
|
v = (GLfloat *)ctx->logged_vertices->data;
|
|
|
|
|
for (i = 0; i < n_vertices; i++)
|
|
|
|
|
{
|
2009-06-16 21:48:21 +00:00
|
|
|
guint8 *c;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
v[0] = vertices[i].x;
|
|
|
|
|
v[1] = vertices[i].y;
|
|
|
|
|
v[2] = vertices[i].z;
|
|
|
|
|
|
2009-06-16 21:48:21 +00:00
|
|
|
if (use_color)
|
|
|
|
|
{
|
|
|
|
|
/* NB: [X,Y,Z,TX,TY,R,G,B,A,...] */
|
|
|
|
|
c = (guint8 *) (v + 5);
|
|
|
|
|
c[0] = cogl_color_get_red_byte (&vertices[i].color);
|
|
|
|
|
c[1] = cogl_color_get_green_byte (&vertices[i].color);
|
|
|
|
|
c[2] = cogl_color_get_blue_byte (&vertices[i].color);
|
|
|
|
|
c[3] = cogl_color_get_alpha_byte (&vertices[i].color);
|
|
|
|
|
}
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
v += stride;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Render all of the slices with the full geometry but use a
|
|
|
|
|
transparent border color so that any part of the texture not
|
|
|
|
|
covered by the slice will be ignored */
|
|
|
|
|
tex_num = 0;
|
|
|
|
|
for (y = 0; y < tex->slice_y_spans->len; y++)
|
|
|
|
|
{
|
|
|
|
|
y_span = &g_array_index (tex->slice_y_spans, CoglTexSliceSpan, y);
|
|
|
|
|
|
|
|
|
|
for (x = 0; x < tex->slice_x_spans->len; x++)
|
|
|
|
|
{
|
|
|
|
|
x_span = &g_array_index (tex->slice_x_spans, CoglTexSliceSpan, x);
|
|
|
|
|
|
|
|
|
|
gl_handle = g_array_index (tex->slice_gl_handles, GLuint, tex_num++);
|
|
|
|
|
|
|
|
|
|
/* Convert the vertices into an array of GLfloats ready to pass to
|
|
|
|
|
OpenGL */
|
|
|
|
|
v = (GLfloat *)ctx->logged_vertices->data;
|
|
|
|
|
for (i = 0; i < n_vertices; i++)
|
|
|
|
|
{
|
|
|
|
|
GLfloat *t;
|
|
|
|
|
float tx, ty;
|
|
|
|
|
|
|
|
|
|
tx = ((vertices[i].tx
|
|
|
|
|
- ((float)(x_span->start)
|
|
|
|
|
/ tex->bitmap.width))
|
|
|
|
|
* tex->bitmap.width / x_span->size);
|
|
|
|
|
ty = ((vertices[i].ty
|
|
|
|
|
- ((float)(y_span->start)
|
|
|
|
|
/ tex->bitmap.height))
|
|
|
|
|
* tex->bitmap.height / y_span->size);
|
|
|
|
|
|
|
|
|
|
#if HAVE_COGL_GL
|
|
|
|
|
/* Scale the coordinates up for rectangle textures */
|
|
|
|
|
if (tex->gl_target == CGL_TEXTURE_RECTANGLE_ARB)
|
|
|
|
|
{
|
|
|
|
|
tx *= x_span->size;
|
|
|
|
|
ty *= y_span->size;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* NB: [X,Y,Z,TX,TY,R,G,B,A,...] */
|
|
|
|
|
t = v + 3;
|
|
|
|
|
t[0] = tx;
|
|
|
|
|
t[1] = ty;
|
|
|
|
|
|
|
|
|
|
v += stride;
|
|
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
options.flags =
|
|
|
|
|
COGL_MATERIAL_FLUSH_DISABLE_MASK |
|
|
|
|
|
COGL_MATERIAL_FLUSH_LAYER0_OVERRIDE;
|
|
|
|
|
/* disable all except the first layer */
|
|
|
|
|
options.disable_layers = (guint32)~1;
|
|
|
|
|
options.layer0_override_texture = gl_handle;
|
|
|
|
|
|
|
|
|
|
_cogl_material_flush_gl_state (ctx->source_material, &options);
|
2009-07-02 23:34:10 +00:00
|
|
|
_cogl_flush_matrix_stacks ();
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
GE( glDrawArrays (GL_TRIANGLE_FAN, 0, n_vertices) );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
_cogl_multitexture_unsliced_polygon (CoglTextureVertex *vertices,
|
|
|
|
|
guint n_vertices,
|
|
|
|
|
guint n_layers,
|
|
|
|
|
guint stride,
|
|
|
|
|
gboolean use_color,
|
[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
|
|
|
guint32 fallback_layers)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
|
|
|
|
CoglHandle material;
|
|
|
|
|
const GList *layers;
|
|
|
|
|
int i;
|
|
|
|
|
GList *tmp;
|
|
|
|
|
CoglTexSliceSpan *y_span, *x_span;
|
|
|
|
|
GLfloat *v;
|
[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
|
|
|
CoglMaterialFlushOptions options;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
material = ctx->source_material;
|
|
|
|
|
layers = cogl_material_get_layers (material);
|
|
|
|
|
|
|
|
|
|
/* Convert the vertices into an array of GLfloats ready to pass to
|
|
|
|
|
OpenGL */
|
|
|
|
|
for (v = (GLfloat *)ctx->logged_vertices->data, i = 0;
|
|
|
|
|
i < n_vertices;
|
|
|
|
|
v += stride, i++)
|
|
|
|
|
{
|
2009-06-16 21:48:21 +00:00
|
|
|
guint8 *c;
|
|
|
|
|
int j;
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
/* NB: [X,Y,Z,TX,TY...,R,G,B,A,...] */
|
|
|
|
|
v[0] = vertices[i].x;
|
|
|
|
|
v[1] = vertices[i].y;
|
|
|
|
|
v[2] = vertices[i].z;
|
|
|
|
|
|
|
|
|
|
for (tmp = (GList *)layers, j = 0; tmp != NULL; tmp = tmp->next, j++)
|
|
|
|
|
{
|
|
|
|
|
CoglHandle layer = (CoglHandle)tmp->data;
|
|
|
|
|
CoglHandle tex_handle;
|
|
|
|
|
CoglTexture *tex;
|
|
|
|
|
GLfloat *t;
|
|
|
|
|
float tx, ty;
|
|
|
|
|
|
|
|
|
|
tex_handle = cogl_material_layer_get_texture (layer);
|
2009-06-19 11:15:12 +00:00
|
|
|
|
|
|
|
|
/* COGL_INVALID_HANDLE textures will be handled in
|
|
|
|
|
* _cogl_material_flush_layers_gl_state but there is no need to worry
|
|
|
|
|
* about scaling texture coordinates in this case */
|
|
|
|
|
if (tex_handle == COGL_INVALID_HANDLE)
|
|
|
|
|
continue;
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
tex = _cogl_texture_pointer_from_handle (tex_handle);
|
|
|
|
|
|
|
|
|
|
y_span = &g_array_index (tex->slice_y_spans, CoglTexSliceSpan, 0);
|
|
|
|
|
x_span = &g_array_index (tex->slice_x_spans, CoglTexSliceSpan, 0);
|
|
|
|
|
|
|
|
|
|
tx = ((vertices[i].tx
|
|
|
|
|
- ((float)(x_span->start)
|
|
|
|
|
/ tex->bitmap.width))
|
|
|
|
|
* tex->bitmap.width / x_span->size);
|
|
|
|
|
ty = ((vertices[i].ty
|
|
|
|
|
- ((float)(y_span->start)
|
|
|
|
|
/ tex->bitmap.height))
|
|
|
|
|
* tex->bitmap.height / y_span->size);
|
|
|
|
|
|
|
|
|
|
#if HAVE_COGL_GL
|
|
|
|
|
/* Scale the coordinates up for rectangle textures */
|
|
|
|
|
if (tex->gl_target == CGL_TEXTURE_RECTANGLE_ARB)
|
|
|
|
|
{
|
|
|
|
|
tx *= x_span->size;
|
|
|
|
|
ty *= y_span->size;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* NB: [X,Y,Z,TX,TY...,R,G,B,A,...] */
|
|
|
|
|
t = v + 3 + 2 * j;
|
|
|
|
|
t[0] = tx;
|
|
|
|
|
t[1] = ty;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-16 21:48:21 +00:00
|
|
|
if (use_color)
|
|
|
|
|
{
|
|
|
|
|
/* NB: [X,Y,Z,TX,TY...,R,G,B,A,...] */
|
|
|
|
|
c = (guint8 *) (v + 3 + 2 * n_layers);
|
|
|
|
|
c[0] = cogl_color_get_red_byte (&vertices[i].color);
|
|
|
|
|
c[1] = cogl_color_get_green_byte (&vertices[i].color);
|
|
|
|
|
c[2] = cogl_color_get_blue_byte (&vertices[i].color);
|
|
|
|
|
c[3] = cogl_color_get_alpha_byte (&vertices[i].color);
|
|
|
|
|
}
|
2009-03-23 12:29:15 +00:00
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
options.flags = COGL_MATERIAL_FLUSH_FALLBACK_MASK;
|
|
|
|
|
if (use_color)
|
|
|
|
|
options.flags |= COGL_MATERIAL_FLUSH_SKIP_GL_COLOR;
|
|
|
|
|
options.fallback_layers = fallback_layers;
|
|
|
|
|
_cogl_material_flush_gl_state (ctx->source_material, &options);
|
2009-07-02 23:34:10 +00:00
|
|
|
_cogl_flush_matrix_stacks ();
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
GE (glDrawArrays (GL_TRIANGLE_FAN, 0, n_vertices));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_polygon (CoglTextureVertex *vertices,
|
|
|
|
|
guint n_vertices,
|
|
|
|
|
gboolean use_color)
|
|
|
|
|
{
|
|
|
|
|
CoglHandle material;
|
|
|
|
|
const GList *layers;
|
|
|
|
|
int n_layers;
|
|
|
|
|
GList *tmp;
|
|
|
|
|
gboolean use_sliced_polygon_fallback = FALSE;
|
[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
|
|
|
guint32 fallback_layers = 0;
|
2009-03-23 12:29:15 +00:00
|
|
|
int i;
|
|
|
|
|
gulong enable_flags;
|
|
|
|
|
guint stride;
|
|
|
|
|
gsize stride_bytes;
|
|
|
|
|
GLfloat *v;
|
|
|
|
|
int prev_n_texcoord_arrays_enabled;
|
|
|
|
|
|
|
|
|
|
_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 ();
|
2009-03-23 12:29:15 +00:00
|
|
|
cogl_clip_ensure ();
|
|
|
|
|
|
|
|
|
|
material = ctx->source_material;
|
|
|
|
|
layers = cogl_material_get_layers (ctx->source_material);
|
|
|
|
|
n_layers = g_list_length ((GList *)layers);
|
|
|
|
|
|
|
|
|
|
for (tmp = (GList *)layers, i = 0; tmp != NULL; tmp = tmp->next, i++)
|
|
|
|
|
{
|
|
|
|
|
CoglHandle layer = (CoglHandle)tmp->data;
|
|
|
|
|
CoglHandle tex_handle = cogl_material_layer_get_texture (layer);
|
|
|
|
|
|
2009-06-19 11:15:12 +00:00
|
|
|
/* COGL_INVALID_HANDLE textures will be handled in
|
|
|
|
|
* _cogl_material_flush_layers_gl_state */
|
|
|
|
|
if (tex_handle == COGL_INVALID_HANDLE)
|
|
|
|
|
continue;
|
|
|
|
|
|
2009-03-23 12:29:15 +00:00
|
|
|
if (i == 0 && cogl_texture_is_sliced (tex_handle))
|
|
|
|
|
{
|
|
|
|
|
#if defined (HAVE_COGL_GLES) || defined (HAVE_COGL_GLES2)
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
g_warning ("cogl_polygon does not work for sliced textures "
|
|
|
|
|
"on GL ES");
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
if (n_layers > 1)
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
{
|
|
|
|
|
g_warning ("Disabling layers 1..n since multi-texturing with "
|
|
|
|
|
"cogl_polygon isn't supported when using sliced "
|
|
|
|
|
"textures\n");
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
use_sliced_polygon_fallback = TRUE;
|
|
|
|
|
n_layers = 1;
|
|
|
|
|
|
2009-06-04 15:04:57 +00:00
|
|
|
if (cogl_material_layer_get_min_filter (layer) != GL_NEAREST
|
|
|
|
|
|| cogl_material_layer_get_mag_filter (layer) != GL_NEAREST)
|
2009-03-23 12:29:15 +00:00
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
{
|
|
|
|
|
g_warning ("cogl_texture_polygon does not work for sliced textures "
|
|
|
|
|
"when the minification and magnification filters are not "
|
|
|
|
|
"CGL_NEAREST");
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef HAVE_COGL_GL
|
2009-06-04 21:20:18 +00:00
|
|
|
{
|
|
|
|
|
CoglTexture *tex = _cogl_texture_pointer_from_handle (tex_handle);
|
|
|
|
|
/* Temporarily change the wrapping mode on all of the slices to use
|
|
|
|
|
* a transparent border
|
|
|
|
|
* XXX: it's doesn't look like we save/restore this, like
|
|
|
|
|
* the comment implies? */
|
|
|
|
|
_cogl_texture_set_wrap_mode_parameter (tex, GL_CLAMP_TO_BORDER);
|
|
|
|
|
}
|
2009-03-23 12:29:15 +00:00
|
|
|
#endif
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (cogl_texture_is_sliced (tex_handle))
|
|
|
|
|
{
|
|
|
|
|
static gboolean warning_seen = FALSE;
|
|
|
|
|
if (!warning_seen)
|
|
|
|
|
g_warning ("Disabling layer %d of the current source material, "
|
|
|
|
|
"because texturing with the vertex buffer API is not "
|
|
|
|
|
"currently supported using sliced textures, or "
|
|
|
|
|
"textures with waste\n", i);
|
|
|
|
|
warning_seen = TRUE;
|
|
|
|
|
|
[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
|
|
|
fallback_layers |= (1 << i);
|
2009-03-23 12:29:15 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Our data is arranged like:
|
|
|
|
|
* [X, Y, Z, TX0, TY0, TX1, TY1..., R, G, B, A,...] */
|
2009-06-16 21:48:21 +00:00
|
|
|
stride = 3 + (2 * n_layers) + (use_color ? 1 : 0);
|
2009-03-23 12:29:15 +00:00
|
|
|
stride_bytes = stride * sizeof (GLfloat);
|
|
|
|
|
|
|
|
|
|
/* Make sure there is enough space in the global vertex
|
|
|
|
|
array. This is used so we can render the polygon with a single
|
|
|
|
|
call to OpenGL but still support any number of vertices */
|
|
|
|
|
g_array_set_size (ctx->logged_vertices, n_vertices * stride);
|
|
|
|
|
v = (GLfloat *)ctx->logged_vertices->data;
|
|
|
|
|
|
|
|
|
|
/* Prepare GL state */
|
|
|
|
|
enable_flags = COGL_ENABLE_VERTEX_ARRAY;
|
2009-05-23 16:42:10 +00:00
|
|
|
enable_flags |= _cogl_material_get_cogl_enable_flags (ctx->source_material);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
if (ctx->enable_backface_culling)
|
|
|
|
|
enable_flags |= COGL_ENABLE_BACKFACE_CULLING;
|
|
|
|
|
|
|
|
|
|
if (use_color)
|
|
|
|
|
{
|
|
|
|
|
enable_flags |= COGL_ENABLE_COLOR_ARRAY;
|
2009-06-16 21:48:21 +00:00
|
|
|
GE( glColorPointer (4, GL_UNSIGNED_BYTE,
|
2009-03-23 12:29:15 +00:00
|
|
|
stride_bytes,
|
|
|
|
|
/* NB: [X,Y,Z,TX,TY...,R,G,B,A,...] */
|
|
|
|
|
v + 3 + 2 * n_layers) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cogl_enable (enable_flags);
|
|
|
|
|
|
|
|
|
|
GE (glVertexPointer (3, GL_FLOAT, stride_bytes, v));
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < n_layers; i++)
|
|
|
|
|
{
|
|
|
|
|
GE (glClientActiveTexture (GL_TEXTURE0 + i));
|
|
|
|
|
GE (glEnableClientState (GL_TEXTURE_COORD_ARRAY));
|
|
|
|
|
GE (glTexCoordPointer (2, GL_FLOAT,
|
|
|
|
|
stride_bytes,
|
|
|
|
|
/* NB: [X,Y,Z,TX,TY...,R,G,B,A,...] */
|
|
|
|
|
v + 3 + 2 * i));
|
|
|
|
|
}
|
|
|
|
|
prev_n_texcoord_arrays_enabled =
|
|
|
|
|
ctx->n_texcoord_arrays_enabled;
|
|
|
|
|
ctx->n_texcoord_arrays_enabled = n_layers;
|
|
|
|
|
for (; i < prev_n_texcoord_arrays_enabled; i++)
|
|
|
|
|
{
|
|
|
|
|
GE (glClientActiveTexture (GL_TEXTURE0 + i));
|
|
|
|
|
GE (glDisableClientState (GL_TEXTURE_COORD_ARRAY));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (use_sliced_polygon_fallback)
|
|
|
|
|
_cogl_texture_sliced_polygon (vertices,
|
|
|
|
|
n_vertices,
|
|
|
|
|
stride,
|
|
|
|
|
use_color);
|
|
|
|
|
else
|
|
|
|
|
_cogl_multitexture_unsliced_polygon (vertices,
|
|
|
|
|
n_vertices,
|
|
|
|
|
n_layers,
|
|
|
|
|
stride,
|
|
|
|
|
use_color,
|
[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
|
|
|
fallback_layers);
|
2009-03-23 12:29:15 +00:00
|
|
|
|
|
|
|
|
/* Reset the size of the logged vertex array because rendering
|
|
|
|
|
rectangles expects it to start at 0 */
|
|
|
|
|
g_array_set_size (ctx->logged_vertices, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2008-05-05 12:01:19 +00:00
|
|
|
void
|
|
|
|
|
cogl_path_fill (void)
|
2008-12-04 13:45:09 +00:00
|
|
|
{
|
|
|
|
|
cogl_path_fill_preserve ();
|
|
|
|
|
|
|
|
|
|
cogl_path_new ();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_path_fill_preserve (void)
|
2008-05-05 12:01:19 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2008-12-04 13:45:09 +00:00
|
|
|
|
[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 ();
|
2008-12-04 13:45:09 +00:00
|
|
|
cogl_clip_ensure ();
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-12-04 13:45:09 +00:00
|
|
|
if (ctx->path_nodes->len == 0)
|
2009-04-27 14:48:12 +00:00
|
|
|
return;
|
2008-12-04 13:45:09 +00:00
|
|
|
|
|
|
|
|
_cogl_path_fill_nodes ();
|
2008-05-05 12:01:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_path_stroke (void)
|
2008-12-04 13:45:09 +00:00
|
|
|
{
|
|
|
|
|
cogl_path_stroke_preserve ();
|
|
|
|
|
|
|
|
|
|
cogl_path_new ();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
cogl_path_stroke_preserve (void)
|
2008-05-05 12:01:19 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-12-04 13:45:09 +00:00
|
|
|
if (ctx->path_nodes->len == 0)
|
2008-05-05 12:01:19 +00:00
|
|
|
return;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
[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 ();
|
|
|
|
|
cogl_clip_ensure ();
|
|
|
|
|
|
2008-05-05 12:01:19 +00:00
|
|
|
_cogl_path_stroke_nodes();
|
|
|
|
|
}
|
2008-04-30 15:05:17 +00:00
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_move_to (float x,
|
|
|
|
|
float y)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* FIXME: handle multiple contours maybe? */
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-12-04 13:45:09 +00:00
|
|
|
_cogl_path_add_node (TRUE, x, y);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
ctx->path_start.x = x;
|
|
|
|
|
ctx->path_start.y = y;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
ctx->path_pen = ctx->path_start;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_rel_move_to (float x,
|
|
|
|
|
float y)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_move_to (ctx->path_pen.x + x,
|
2008-05-05 10:25:11 +00:00
|
|
|
ctx->path_pen.y + y);
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_line_to (float x,
|
|
|
|
|
float y)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-12-04 13:45:09 +00:00
|
|
|
_cogl_path_add_node (FALSE, x, y);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
ctx->path_pen.x = x;
|
|
|
|
|
ctx->path_pen.y = y;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_rel_line_to (float x,
|
|
|
|
|
float y)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_line_to (ctx->path_pen.x + x,
|
|
|
|
|
ctx->path_pen.y + y);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2008-05-05 10:25:11 +00:00
|
|
|
cogl_path_close (void)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-12-04 13:45:09 +00:00
|
|
|
_cogl_path_add_node (FALSE, ctx->path_start.x, ctx->path_start.y);
|
2008-04-30 15:05:17 +00:00
|
|
|
ctx->path_pen = ctx->path_start;
|
|
|
|
|
}
|
|
|
|
|
|
2008-12-04 13:45:09 +00:00
|
|
|
void
|
|
|
|
|
cogl_path_new (void)
|
|
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
|
|
g_array_set_size (ctx->path_nodes, 0);
|
|
|
|
|
}
|
2008-04-30 15:05:17 +00:00
|
|
|
|
|
|
|
|
void
|
2009-01-23 13:08:46 +00:00
|
|
|
cogl_path_line (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
2009-01-23 13:08:46 +00:00
|
|
|
cogl_path_move_to (x_1, y_1);
|
|
|
|
|
cogl_path_line_to (x_2, y_2);
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_polyline (float *coords,
|
2008-05-05 10:25:11 +00:00
|
|
|
gint num_points)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
gint c = 0;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_move_to (coords[0], coords[1]);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
for (c = 1; c < num_points; ++c)
|
|
|
|
|
cogl_path_line_to (coords[2*c], coords[2*c+1]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_polygon (float *coords,
|
2008-05-05 10:25:11 +00:00
|
|
|
gint num_points)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
2008-05-05 10:25:11 +00:00
|
|
|
cogl_path_polyline (coords, num_points);
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_close ();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-03-13 15:28:20 +00:00
|
|
|
cogl_path_rectangle (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
2009-03-13 15:28:20 +00:00
|
|
|
cogl_path_move_to (x_1, y_1);
|
|
|
|
|
cogl_path_line_to (x_2, y_1);
|
|
|
|
|
cogl_path_line_to (x_2, y_2);
|
|
|
|
|
cogl_path_line_to (x_1, y_2);
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_close ();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2009-01-20 16:20:54 +00:00
|
|
|
_cogl_path_arc (float center_x,
|
|
|
|
|
float center_y,
|
|
|
|
|
float radius_x,
|
|
|
|
|
float radius_y,
|
|
|
|
|
float angle_1,
|
|
|
|
|
float angle_2,
|
|
|
|
|
float angle_step,
|
2008-05-05 10:25:11 +00:00
|
|
|
guint move_first)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
2009-01-20 16:20:54 +00:00
|
|
|
float a = 0x0;
|
|
|
|
|
float cosa = 0x0;
|
|
|
|
|
float sina = 0x0;
|
|
|
|
|
float px = 0x0;
|
|
|
|
|
float py = 0x0;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Fix invalid angles */
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
if (angle_1 == angle_2 || angle_step == 0x0)
|
|
|
|
|
return;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
if (angle_step < 0x0)
|
|
|
|
|
angle_step = -angle_step;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Walk the arc by given step */
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-06-10 10:05:12 +00:00
|
|
|
a = angle_1;
|
|
|
|
|
while (a != angle_2)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
2009-01-20 16:20:54 +00:00
|
|
|
cosa = cosf (a * (G_PI/180.0));
|
|
|
|
|
sina = sinf (a * (G_PI/180.0));
|
2008-04-30 15:05:17 +00:00
|
|
|
|
2009-01-20 16:20:54 +00:00
|
|
|
px = center_x + (cosa * radius_x);
|
|
|
|
|
py = center_y + (sina * radius_y);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
if (a == angle_1 && move_first)
|
|
|
|
|
cogl_path_move_to (px, py);
|
|
|
|
|
else
|
|
|
|
|
cogl_path_line_to (px, py);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-06-10 10:05:12 +00:00
|
|
|
if (G_LIKELY (angle_2 > angle_1))
|
|
|
|
|
{
|
|
|
|
|
a += angle_step;
|
|
|
|
|
if (a > angle_2)
|
|
|
|
|
a = angle_2;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
a -= angle_step;
|
|
|
|
|
if (a < angle_2)
|
|
|
|
|
a = angle_2;
|
|
|
|
|
}
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
2008-06-10 10:05:12 +00:00
|
|
|
|
|
|
|
|
/* Make sure the final point is drawn */
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2009-01-20 16:20:54 +00:00
|
|
|
cosa = cosf (angle_2 * (G_PI/180.0));
|
|
|
|
|
sina = sinf (angle_2 * (G_PI/180.0));
|
2008-06-10 10:05:12 +00:00
|
|
|
|
2009-01-20 16:20:54 +00:00
|
|
|
px = center_x + (cosa * radius_x);
|
|
|
|
|
py = center_y + (sina * radius_y);
|
2008-06-10 10:05:12 +00:00
|
|
|
|
|
|
|
|
cogl_path_line_to (px, py);
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_arc (float center_x,
|
|
|
|
|
float center_y,
|
|
|
|
|
float radius_x,
|
|
|
|
|
float radius_y,
|
|
|
|
|
float angle_1,
|
|
|
|
|
float angle_2)
|
2009-04-27 14:48:12 +00:00
|
|
|
{
|
2009-01-20 16:20:54 +00:00
|
|
|
float angle_step = 10;
|
2008-05-05 10:25:11 +00:00
|
|
|
/* it is documented that a move to is needed to create a freestanding
|
|
|
|
|
* arc
|
|
|
|
|
*/
|
|
|
|
|
_cogl_path_arc (center_x, center_y,
|
|
|
|
|
radius_x, radius_y,
|
|
|
|
|
angle_1, angle_2,
|
|
|
|
|
angle_step, 0 /* no move */);
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_arc_rel (float center_x,
|
|
|
|
|
float center_y,
|
|
|
|
|
float radius_x,
|
|
|
|
|
float radius_y,
|
|
|
|
|
float angle_1,
|
|
|
|
|
float angle_2,
|
|
|
|
|
float angle_step)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
_cogl_path_arc (ctx->path_pen.x + center_x,
|
|
|
|
|
ctx->path_pen.y + center_y,
|
|
|
|
|
radius_x, radius_y,
|
|
|
|
|
angle_1, angle_2,
|
|
|
|
|
angle_step, 0 /* no move */);
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-20 16:20:54 +00:00
|
|
|
cogl_path_ellipse (float center_x,
|
|
|
|
|
float center_y,
|
|
|
|
|
float radius_x,
|
|
|
|
|
float radius_y)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
2009-01-20 16:20:54 +00:00
|
|
|
float angle_step = 10;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* FIXME: if shows to be slow might be optimized
|
|
|
|
|
* by mirroring just a quarter of it */
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
_cogl_path_arc (center_x, center_y,
|
|
|
|
|
radius_x, radius_y,
|
2009-01-20 16:20:54 +00:00
|
|
|
0, 360,
|
2008-05-05 10:25:11 +00:00
|
|
|
angle_step, 1 /* move first */);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_close();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-03-13 15:28:20 +00:00
|
|
|
cogl_path_round_rectangle (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
2009-01-20 16:20:54 +00:00
|
|
|
float radius,
|
|
|
|
|
float arc_step)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
2009-03-13 15:28:20 +00:00
|
|
|
float inner_width = x_2 - x_1 - radius * 2;
|
|
|
|
|
float inner_height = y_2 - y_1 - radius * 2;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-06-23 11:01:30 +00:00
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
2009-03-13 15:28:20 +00:00
|
|
|
cogl_path_move_to (x_1, y_1 + radius);
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_arc_rel (radius, 0,
|
|
|
|
|
radius, radius,
|
2009-01-20 16:20:54 +00:00
|
|
|
180,
|
|
|
|
|
270,
|
2008-04-30 15:05:17 +00:00
|
|
|
arc_step);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_line_to (ctx->path_pen.x + inner_width,
|
|
|
|
|
ctx->path_pen.y);
|
|
|
|
|
cogl_path_arc_rel (0, radius,
|
|
|
|
|
radius, radius,
|
2009-01-20 16:20:54 +00:00
|
|
|
-90,
|
|
|
|
|
0,
|
2008-04-30 15:05:17 +00:00
|
|
|
arc_step);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_line_to (ctx->path_pen.x,
|
|
|
|
|
ctx->path_pen.y + inner_height);
|
|
|
|
|
|
|
|
|
|
cogl_path_arc_rel (-radius, 0,
|
|
|
|
|
radius, radius,
|
2009-01-20 16:20:54 +00:00
|
|
|
0,
|
|
|
|
|
90,
|
2008-04-30 15:05:17 +00:00
|
|
|
arc_step);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_line_to (ctx->path_pen.x - inner_width,
|
|
|
|
|
ctx->path_pen.y);
|
|
|
|
|
cogl_path_arc_rel (0, -radius,
|
|
|
|
|
radius, radius,
|
2009-01-20 16:20:54 +00:00
|
|
|
90,
|
|
|
|
|
180,
|
2008-04-30 15:05:17 +00:00
|
|
|
arc_step);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
cogl_path_close ();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
_cogl_path_bezier3_sub (CoglBezCubic *cubic)
|
|
|
|
|
{
|
|
|
|
|
CoglBezCubic cubics[_COGL_MAX_BEZ_RECURSE_DEPTH];
|
|
|
|
|
CoglBezCubic *cleft;
|
|
|
|
|
CoglBezCubic *cright;
|
|
|
|
|
CoglBezCubic *c;
|
2009-01-20 16:20:54 +00:00
|
|
|
floatVec2 dif1;
|
|
|
|
|
floatVec2 dif2;
|
|
|
|
|
floatVec2 mm;
|
|
|
|
|
floatVec2 c1;
|
|
|
|
|
floatVec2 c2;
|
|
|
|
|
floatVec2 c3;
|
|
|
|
|
floatVec2 c4;
|
|
|
|
|
floatVec2 c5;
|
2008-04-30 15:05:17 +00:00
|
|
|
gint cindex;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Put first curve on stack */
|
|
|
|
|
cubics[0] = *cubic;
|
|
|
|
|
cindex = 0;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
while (cindex >= 0)
|
|
|
|
|
{
|
|
|
|
|
c = &cubics[cindex];
|
2009-04-27 14:48:12 +00:00
|
|
|
|
|
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Calculate distance of control points from their
|
|
|
|
|
* counterparts on the line between end points */
|
2009-01-20 16:20:54 +00:00
|
|
|
dif1.x = (c->p2.x * 3) - (c->p1.x * 2) - c->p4.x;
|
|
|
|
|
dif1.y = (c->p2.y * 3) - (c->p1.y * 2) - c->p4.y;
|
|
|
|
|
dif2.x = (c->p3.x * 3) - (c->p4.x * 2) - c->p1.x;
|
|
|
|
|
dif2.y = (c->p3.y * 3) - (c->p4.y * 2) - c->p1.y;
|
2008-10-30 16:37:55 +00:00
|
|
|
|
|
|
|
|
if (dif1.x < 0)
|
|
|
|
|
dif1.x = -dif1.x;
|
|
|
|
|
if (dif1.y < 0)
|
|
|
|
|
dif1.y = -dif1.y;
|
|
|
|
|
if (dif2.x < 0)
|
|
|
|
|
dif2.x = -dif2.x;
|
|
|
|
|
if (dif2.y < 0)
|
|
|
|
|
dif2.y = -dif2.y;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
|
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Pick the greatest of two distances */
|
|
|
|
|
if (dif1.x < dif2.x) dif1.x = dif2.x;
|
|
|
|
|
if (dif1.y < dif2.y) dif1.y = dif2.y;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Cancel if the curve is flat enough */
|
2009-01-20 16:20:54 +00:00
|
|
|
if (dif1.x + dif1.y <= 1.0 ||
|
2008-10-30 16:37:55 +00:00
|
|
|
cindex == _COGL_MAX_BEZ_RECURSE_DEPTH-1)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
/* Add subdivision point (skip last) */
|
2008-10-30 16:37:55 +00:00
|
|
|
if (cindex == 0)
|
|
|
|
|
return;
|
|
|
|
|
|
2008-12-04 13:45:09 +00:00
|
|
|
_cogl_path_add_node (FALSE, c->p4.x, c->p4.y);
|
2008-10-30 16:37:55 +00:00
|
|
|
|
|
|
|
|
--cindex;
|
|
|
|
|
|
|
|
|
|
continue;
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Left recursion goes on top of stack! */
|
|
|
|
|
cright = c; cleft = &cubics[++cindex];
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Subdivide into 2 sub-curves */
|
2009-01-20 16:20:54 +00:00
|
|
|
c1.x = ((c->p1.x + c->p2.x) / 2);
|
|
|
|
|
c1.y = ((c->p1.y + c->p2.y) / 2);
|
|
|
|
|
mm.x = ((c->p2.x + c->p3.x) / 2);
|
|
|
|
|
mm.y = ((c->p2.y + c->p3.y) / 2);
|
|
|
|
|
c5.x = ((c->p3.x + c->p4.x) / 2);
|
|
|
|
|
c5.y = ((c->p3.y + c->p4.y) / 2);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2009-01-20 16:20:54 +00:00
|
|
|
c2.x = ((c1.x + mm.x) / 2);
|
|
|
|
|
c2.y = ((c1.y + mm.y) / 2);
|
|
|
|
|
c4.x = ((mm.x + c5.x) / 2);
|
|
|
|
|
c4.y = ((mm.y + c5.y) / 2);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2009-01-20 16:20:54 +00:00
|
|
|
c3.x = ((c2.x + c4.x) / 2);
|
|
|
|
|
c3.y = ((c2.y + c4.y) / 2);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Add left recursion to stack */
|
|
|
|
|
cleft->p1 = c->p1;
|
|
|
|
|
cleft->p2 = c1;
|
|
|
|
|
cleft->p3 = c2;
|
|
|
|
|
cleft->p4 = c3;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Add right recursion to stack */
|
|
|
|
|
cright->p1 = c3;
|
|
|
|
|
cright->p2 = c4;
|
|
|
|
|
cright->p3 = c5;
|
|
|
|
|
cright->p4 = c->p4;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-23 13:08:46 +00:00
|
|
|
cogl_path_curve_to (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
|
|
|
|
float x_3,
|
|
|
|
|
float y_3)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
CoglBezCubic cubic;
|
2008-06-23 11:01:30 +00:00
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Prepare cubic curve */
|
|
|
|
|
cubic.p1 = ctx->path_pen;
|
2009-01-23 13:08:46 +00:00
|
|
|
cubic.p2.x = x_1;
|
|
|
|
|
cubic.p2.y = y_1;
|
|
|
|
|
cubic.p3.x = x_2;
|
|
|
|
|
cubic.p3.y = y_2;
|
|
|
|
|
cubic.p4.x = x_3;
|
|
|
|
|
cubic.p4.y = y_3;
|
2008-06-23 11:01:30 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Run subdivision */
|
|
|
|
|
_cogl_path_bezier3_sub (&cubic);
|
2008-06-23 11:01:30 +00:00
|
|
|
|
2008-04-30 15:05:17 +00:00
|
|
|
/* Add last point */
|
2008-12-04 13:45:09 +00:00
|
|
|
_cogl_path_add_node (FALSE, cubic.p4.x, cubic.p4.y);
|
2008-04-30 15:05:17 +00:00
|
|
|
ctx->path_pen = cubic.p4;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-23 13:08:46 +00:00
|
|
|
cogl_path_rel_curve_to (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2,
|
|
|
|
|
float x_3,
|
|
|
|
|
float y_3)
|
2008-04-30 15:05:17 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2009-01-23 13:08:46 +00:00
|
|
|
cogl_path_curve_to (ctx->path_pen.x + x_1,
|
|
|
|
|
ctx->path_pen.y + y_1,
|
|
|
|
|
ctx->path_pen.x + x_2,
|
|
|
|
|
ctx->path_pen.y + y_2,
|
|
|
|
|
ctx->path_pen.x + x_3,
|
|
|
|
|
ctx->path_pen.y + y_3);
|
2008-04-30 15:05:17 +00:00
|
|
|
}
|
2008-05-05 10:25:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/* If second order beziers were needed the following code could
|
|
|
|
|
* be re-enabled:
|
|
|
|
|
*/
|
|
|
|
|
#if 0
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
_cogl_path_bezier2_sub (CoglBezQuad *quad)
|
|
|
|
|
{
|
|
|
|
|
CoglBezQuad quads[_COGL_MAX_BEZ_RECURSE_DEPTH];
|
|
|
|
|
CoglBezQuad *qleft;
|
|
|
|
|
CoglBezQuad *qright;
|
|
|
|
|
CoglBezQuad *q;
|
2009-01-20 16:20:54 +00:00
|
|
|
floatVec2 mid;
|
|
|
|
|
floatVec2 dif;
|
|
|
|
|
floatVec2 c1;
|
|
|
|
|
floatVec2 c2;
|
|
|
|
|
floatVec2 c3;
|
2008-05-05 10:25:11 +00:00
|
|
|
gint qindex;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Put first curve on stack */
|
|
|
|
|
quads[0] = *quad;
|
|
|
|
|
qindex = 0;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* While stack is not empty */
|
|
|
|
|
while (qindex >= 0)
|
|
|
|
|
{
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
q = &quads[qindex];
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Calculate distance of control point from its
|
|
|
|
|
* counterpart on the line between end points */
|
2009-01-20 16:20:54 +00:00
|
|
|
mid.x = ((q->p1.x + q->p3.x) / 2);
|
|
|
|
|
mid.y = ((q->p1.y + q->p3.y) / 2);
|
2008-05-05 10:25:11 +00:00
|
|
|
dif.x = (q->p2.x - mid.x);
|
|
|
|
|
dif.y = (q->p2.y - mid.y);
|
|
|
|
|
if (dif.x < 0) dif.x = -dif.x;
|
|
|
|
|
if (dif.y < 0) dif.y = -dif.y;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Cancel if the curve is flat enough */
|
2009-01-20 16:20:54 +00:00
|
|
|
if (dif.x + dif.y <= 1.0 ||
|
2008-10-30 16:37:55 +00:00
|
|
|
qindex == _COGL_MAX_BEZ_RECURSE_DEPTH - 1)
|
2008-05-05 10:25:11 +00:00
|
|
|
{
|
|
|
|
|
/* Add subdivision point (skip last) */
|
|
|
|
|
if (qindex == 0) return;
|
2008-12-04 13:45:09 +00:00
|
|
|
_cogl_path_add_node (FALSE, q->p3.x, q->p3.y);
|
2008-05-05 10:25:11 +00:00
|
|
|
--qindex; continue;
|
|
|
|
|
}
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Left recursion goes on top of stack! */
|
|
|
|
|
qright = q; qleft = &quads[++qindex];
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Subdivide into 2 sub-curves */
|
2009-01-20 16:20:54 +00:00
|
|
|
c1.x = ((q->p1.x + q->p2.x) / 2);
|
|
|
|
|
c1.y = ((q->p1.y + q->p2.y) / 2);
|
|
|
|
|
c3.x = ((q->p2.x + q->p3.x) / 2);
|
|
|
|
|
c3.y = ((q->p2.y + q->p3.y) / 2);
|
|
|
|
|
c2.x = ((c1.x + c3.x) / 2);
|
|
|
|
|
c2.y = ((c1.y + c3.y) / 2);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Add left recursion onto stack */
|
|
|
|
|
qleft->p1 = q->p1;
|
|
|
|
|
qleft->p2 = c1;
|
|
|
|
|
qleft->p3 = c2;
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Add right recursion onto stack */
|
|
|
|
|
qright->p1 = c2;
|
|
|
|
|
qright->p2 = c3;
|
|
|
|
|
qright->p3 = q->p3;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-23 13:08:46 +00:00
|
|
|
cogl_path_curve2_to (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2)
|
2008-05-05 10:25:11 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-01-23 13:08:46 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
CoglBezQuad quad;
|
2009-01-23 13:08:46 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Prepare quadratic curve */
|
|
|
|
|
quad.p1 = ctx->path_pen;
|
2009-01-23 13:08:46 +00:00
|
|
|
quad.p2.x = x_1;
|
|
|
|
|
quad.p2.y = y_1;
|
|
|
|
|
quad.p3.x = x_2;
|
|
|
|
|
quad.p3.y = y_2;
|
|
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Run subdivision */
|
|
|
|
|
_cogl_path_bezier2_sub (&quad);
|
2009-04-27 14:48:12 +00:00
|
|
|
|
2008-05-05 10:25:11 +00:00
|
|
|
/* Add last point */
|
2008-12-04 13:45:09 +00:00
|
|
|
_cogl_path_add_node (FALSE, quad.p3.x, quad.p3.y);
|
2008-05-05 10:25:11 +00:00
|
|
|
ctx->path_pen = quad.p3;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2009-01-23 13:08:46 +00:00
|
|
|
cogl_rel_curve2_to (float x_1,
|
|
|
|
|
float y_1,
|
|
|
|
|
float x_2,
|
|
|
|
|
float y_2)
|
2008-05-05 10:25:11 +00:00
|
|
|
{
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
2009-01-23 13:08:46 +00:00
|
|
|
|
|
|
|
|
cogl_path_curve2_to (ctx->path_pen.x + x_1,
|
|
|
|
|
ctx->path_pen.y + y_1,
|
|
|
|
|
ctx->path_pen.x + x_2,
|
|
|
|
|
ctx->path_pen.y + y_2);
|
2008-05-05 10:25:11 +00:00
|
|
|
}
|
|
|
|
|
#endif
|