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.
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.
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 ()
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
The symbol name for cogl_vertex_buffer_draw_elements was wrong so it
ended up with no documentation. The name for the vertex attribute was
incorrect in cogl_vertex_buffer_add.
This function was renamed a while ago in the .c file from
cogl_vertex_buffer_draw_range_elements but the corresponding .h and
doc/reference/cogl changes weren't made.
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.)
This hides a number of internal structs and enums from the docs, and moves
some functions to more appropriate sections as well as misc description
updates (mostly for 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.
