Commit Graph

26 Commits

Author SHA1 Message Date
Robert Bragg
845ff67301 [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-30 17:13:34 +01:00
Robert Bragg
8f734ccbb4 [vertex-buffer] Add cogl_vertex_buffer_indices_get_type API
cogl_vertex_buffer_indices lets you query back the data type used for the
given indices handle.
2009-06-29 23:49:05 +01:00
Colin Walters
63c84c46f8 Plug minor memory leak in cogl_vertex_buffer_submit_real
Free a temporary list.
2009-06-16 15:46:51 +01:00
Emmanuele Bassi
02fa34f65b Fix a compiler warning 2009-06-05 16:39:18 +01:00
Neil Roberts
67544f38d4 [cogl-vertex-buffer] Add cogl_vertex_buffer_indices_get_for_quads
This function can be used as an efficient way of drawing groups of
quads without using GL_QUADS. It generates a VBO containing the
indices needed to render using pairs of GL_TRIANGLES. The VBO is
globally cached so that it only needs to be uploaded whenever more
indices are requested than ever before.
2009-06-01 14:50:52 +01:00
Robert Bragg
be826ed4e7 [cogl vertex buffers] Give indices a CoglHandle so they are shareable
Previously indices were tightly bound to a particular Cogl vertex buffer
but we would like to be able to share indices so now we have
cogl_vertex_buffer_indices_new () which returns a CoglHandle.

In particular we could like to have a shared set of indices for drawing
lists of quads that can be shared between the pango renderer and the
Cogl journal.
2009-05-28 13:27:54 +01:00
Robert Bragg
59bd824404 [vbo indices] tweak add_indices api to return an id and add delete_indices api
Originally cogl_vertex_buffer_add_indices let the user pass in their own unique
ID for the indices; now the Id is generated internally and returned to the
caller.
2009-05-28 02:43:35 +01:00
Robert Bragg
d51faed660 [cogl-vertex-buffer] Seal GL types from the public API
We now have CoglAttributeType and CoglVerticesMode typedefs to replace the
use of GLenum in the public API.
2009-05-28 02:43:35 +01:00
Robert Bragg
6bb6686666 [cogl-vertex-buffers] Support putting index arrays into VBOS
It's now possible to add arrays of indices to a Cogl vertex buffer and
they will be put into an OpenGL vertex buffer object. Since it's quite
common for index arrays to be static it saves the OpenGL driver from
having to validate them repeatedly.

This changes the cogl_vertex_buffer_draw_elements API: It's no longer
possible to provide a pointer to an index array at draw time. So
cogl_vertex_buffer_draw_elements now takes an indices identifier that
should correspond to an idendifier returned when calling
cogl_vertex_buffer_add_indices ()
2009-05-28 02:43:34 +01:00
Robert Bragg
f322da3794 [material] Reduce the material API in preperation for releasing Clutter 1.0
There were a number of functions intended to support creating of new
primitives using materials, but at this point they aren't used outside of
Cogl so until someone has a usecase and we can get feedback on this
API, it's being removed before we release Clutter 1.0.
2009-05-28 02:43:34 +01:00
Neil Roberts
b3fe1b8a8a [cogl-vertex-buffer] Ensure the clip state before rendering
Before any rendering is done by Cogl it needs to ensure the clip stack
is set up correctly by calling cogl_clip_ensure. This was not being
done for the Cogl vertex buffer so it would still use the clip from
the previous render.
2009-05-22 11:48:34 +01:00
Neil Roberts
f13c3ee309 Make backface culling work with vertex buffers
Backface culling is enabled as part of cogl_enable so the different
rendering functions in Cogl need to explicitly opt-in to have backface
culling enabled. Cogl vertex buffers should allow backface culling so
they should check whether it is enabled and then set the appropriate
cogl_enable flag.
2009-05-21 14:57:07 +01:00
Emmanuele Bassi
c74586d019 [cogl] Do no include gprintf.h
We are not using any of the g_printf* family of functions, so we
can import glib.h instead.
2009-05-20 15:21:32 +01:00
Robert Bragg
f85377372c [cogl] Updates all file headers and removes lots of trailing white space
Adds missing notices, and ensures all the notices are consistent. The Cogl
blurb also now reads:

 * Cogl
 *
 * An object oriented GL/GLES Abstraction/Utility Layer
2009-05-02 04:12:25 +01:00
Robert Bragg
46c20f1523 [cogl vertex buffers] Adds fallbacks for drivers without VBO support
Buffer objects aren't currently available for glx indirect contexts, so we
now have a fallback that simply allocates fake client side vbos to store the
attributes.
2009-04-20 13:04:34 +01:00
Robert Bragg
c3d9f0bed4 [cogl-handle] Optimize how we define cogl handles
The cogl_is_* functions were showing up quite high on profiles due to
iterating through arrays of cogl handles.

This does away with all the handle arrays and implements a simple struct
inheritance scheme. All cogl objects now add a CoglHandleObject _parent;
member to their main structures. The base object includes 2 members a.t.m; a
ref_count, and a klass pointer. The klass in turn gives you a type and
virtual function for freeing objects of that type.

Each handle type has a _cogl_##handle_type##_get_type () function
automatically defined which returns a GQuark of the handle type, so now
implementing the cogl_is_* funcs is just a case of comparing with
obj->klass->type.

Another outcome of the re-work is that cogl_handle_{ref,unref} are also much
more efficient, and no longer need extending for each handle type added to
cogl. The cogl_##handle_type##_{ref,unref} functions are now deprecated and
are no longer used internally to Clutter or Cogl. Potentially we can remove
them completely before 1.0.
2009-04-02 11:58:43 +01:00
Robert Bragg
3d81f0c08e [build] Fixes a cogl-vertex-buffer.c warning when building for GLES
GLES 1 doesn't support GLSL so it never needs to use the generic_index
variable for generic attributes which was flagging a warning.
2009-03-23 16:32:17 +00:00
Robert Bragg
14e6323554 [cogl-vertex-buffer] Allow querying back the number of vertices a buffer represents
This may be convenient e.g. at draw time if you are simply drawing all vertices
2009-03-16 16:17:02 +00:00
Robert Bragg
075ae9c4a7 [cogl-vertex-buffer] Add a flush of attribute changes in the *_draw() functions
For convenience it is now valid to avoid a seperate call to
cogl_vertex_buffer_submit() and assume that the _draw() calls will do this
for you (though of course if you do this you still need to ensure the
attribute pointers remain valid until your draw call.)
2009-03-16 16:14:17 +00:00
Havoc Pennington
08932584b5 Virtualize GL matrix operations and use a client-side matrix when GL is indirect
This is useful because sometimes we need to get the current matrix, which
is too expensive when indirect rendering.

In addition, this virtualization makes it easier to clean up the API in
the future.
2009-03-12 18:32:45 +00:00
Robert Bragg
8d04fbb05e [Cogl] Remove a debugging assert that was triggering on false positives
An assert to verify there was no error when generating a buffer object
for the vertex buffer API was being hit when running the GLES1 conformance
tests.
2009-02-23 10:49:35 +00:00
Neil Roberts
9e10dc402f Call glActiveTexture and glClientActiveTexture through cogl_get_proc_address
All GL functions that are defined in a version later than 1.1 need to
be called through cogl_get_proc_address because the Windows GL DLL
does not export them to directly link against.
2009-02-16 12:46:36 +00:00
Robert Bragg
d01e3cd802 [cogl-vertex-buffer] Some fixes for texturing and color arrays
Fixes some blending issues when using color arrays since we were
conflicting with the cogl_enable state + fixes a texture layer
validation bug.

Adds a basic textured triangle to test-vertex-buffer-contiguous.
2009-02-09 14:15:06 +00:00
Neil Roberts
e88de5f5fd Fix building GLES 2 after the material branch merge
- In cogl-material.h it directly sets the values of the
  CoglMaterialLayerCombineFunc to some GL_* constants. However these
  aren't defined in GLES 2 beacuse it has no fixed function texture
  combining. Instead the CGL_* versions are now used. cogl-defines.h
  now sets these to either the GL_* version if it is available,
  otherwise it directly uses the number.

- Under GLES 2 cogl-material.c needs to access the CoglTexture struct
  so it needs to include cogl-texture-private.h

- There are now #define's in cogl-gles2-wrapper.h to remap the GL
  function names to the wrapper names. These are disabled in
  cogl-gles2-wrapper.c by defining COGL_GLES2_WRAPPER_NO_REMAP.

- Added missing wrappers for glLoadMatrixf and glMaterialfv.

- Renamed the TexEnvf wrapper to TexEnvi because the latter is used
  instead from the material API.
2009-02-02 21:57:41 +00:00
Robert Bragg
5985eef44c 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-27 14:26:39 +00:00
Robert Bragg
e338245827 Renames the mesh api to the "vertex buffer api".
This better reflects the fact that the api manages sets of vertex attributes,
and the attributes really have no implied form. It is only when you use the
attributes to draw that they become mesh like; when you specify how they should
be interpreted, e.g. as triangle lists or fans etc. This rename frees up the
term "mesh", which can later be applied to a concept slightly more fitting.
E.g. at some point it would be nice to have a higher level abstraction that
sits on top of cogl vertex buffers that adds the concept of faces. (Somthing
like Blender's mesh objects.) There have also been some discussions over
particle engines, and these can be defined in terms of emitter faces; so some
other kind of mesh abstraction might be usefull here.
2009-01-20 22:29:35 +00:00