The coding style has for a long time said to avoid using redundant glib
data types such as gint or gchar etc because we feel that they make the
code look unnecessarily foreign to developers coming from outside of the
Gnome developer community.
Note: When we tried to find the historical rationale for the types we
just found that they were apparently only added for consistent syntax
highlighting which didn't seem that compelling.
Up until now we have been continuing to use some of the platform
specific type such as gint{8,16,32,64} and gsize but this patch switches
us over to using the standard c99 equivalents instead so we can further
ensure that our code looks familiar to the widest range of C developers
who might potentially contribute to Cogl.
So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this
switches all Cogl code to instead use the int{8,16,32,64}_t and
uint{8,16,32,64}_t c99 types instead.
Instead of gsize we now use size_t
For now we are not going to use the c99 _Bool type and instead we have
introduced a new CoglBool type to use instead of gboolean.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
Removing CoglHandle has been an on going goal for quite a long time now
and finally this patch removes the last remaining uses of the CoglHandle
type and the cogl_handle_ apis.
Since the big remaining users of CoglHandle were the cogl_program_ and
cogl_shader_ apis which have replaced with the CoglSnippets api this
patch removes both of these apis.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6ed3aaf4be21d605a1ed3176b3ea825933f85cf0)
Since the original patch was done after removing deprecated API
this back ported patch doesn't affect deprecated API and so
actually this cherry-pick doesn't remove all remaining use of
CoglHandle as it did for the master branch of Cogl.
This creates a CoglBitmap which points into an existing buffer in
system memory. That way it can be used to create a texture or to read
pixel data into. The function replaces the existing internal function
_cogl_bitmap_new_from_data but removes the destroy notify call back.
If the application wants notification of destruction it can just use
the cogl_object_set_user_data function as normal. Internally there is
now a convenience function to create a bitmap for system memory and
automatically free the buffer using that mechanism.
The name of the function is inspired by
cairo_image_surface_create_for_data which has similar semantics.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds a small cogl_bitmap_get_buffer public function. Note that
this can return NULL if the bitmap was not created with a pixel
buffer. It might be nice to change this eventually so that all bitmaps
have a pixel buffer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The idea is that CoglPixelBuffer should just be a buffer that can be
used for pixel data and it has no idea about the details of any images
that are stored in it. This is analogous to CoglAttributeBuffer which
itself does not have any information about the attributes. When you
want to use a pixel buffer you should create a CoglBitmap which points
to a region of the attribute buffer and provides the extra needed
information such as the width, height and format. That way it is also
possible to use a single CoglPixelBuffer with multiple bitmaps.
The changes that are made are:
• cogl_pixel_buffer_new_with_size has been removed and in its place is
cogl_bitmap_new_with_size. This will create a pixel buffer at the
right size and rowstride for the given width/height/format and
immediately create a single CoglBitmap to point into it. The old
function had an out-parameter for the stride of the image but with
the new API this should be queriable from the bitmap (although there
is no function for this yet).
• There is now a public cogl_pixel_buffer_new constructor. This takes
a size in bytes and data pointer similarly to
cogl_attribute_buffer_new.
• cogl_texture_new_from_buffer has been removed. If you want to create
a texture from a pixel buffer you should wrap it up in a bitmap
first. There is already API to create a texture from a bitmap.
This patch also does a bit of header juggling because cogl-context.h
was including cogl-texture.h and cogl-framebuffer.h which were causing
some circular dependencies when cogl-bitmap.h includes cogl-context.h.
These weren't actually needed in cogl-context.h itself but a few other
headers were relying on them being included so this adds the #includes
where necessary.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Originally we decided to use #define tricks to rename all experimental
symbols so that they had an _EXP suffix so it would be a bit clearer for
those wanting to check for ABI changes that they shouldn't worry about
these experimental symbols.
We feel now though that the defines are a bit more hassle than they are
really worth, since they are one extra thing to remember when coding,
they make using gdb slightly more awkward since you have to use the real
symbol name to set breakpoints and we already have a mechanism for
declaring symbols as experimental via gtk-doc that can be used by anyone
wanting to check for ABI changes.
Instead of just using a script to remove all the #defines we are going
to go through them manually because we need to make sure the symbols
are marked as unstable via gtk-doc. This patch does a first batch of
define removals and in fact some of the symbols didn't have any
documentation at all so that needed to be added too.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This exposes 2 experimental functions that make it possible to upload a
subregion of a texture from a CoglBuffer by first wrapping the buffer as
a CoglBitmap and then allowing uploading of a subregion from a
CoglBitmap. The new functions are:
cogl_bitmap_new_from_buffer() and
cogl_texture_set_region_from_bitmap()
Actually for now we are exporting this API for practical reasons since
we already had this API internally and it enables a specific feature
that was requested, but it is worth nothing that it's quite likely we
will replace these with functions that don't involve the CoglBitmap API
at some point.
For reference: The CoglBitmap API was actually removed from the 2.0
experimental API reference manual some time ago because the hope was
that we'd come up with a neater replacement. It doesn't seem entirely
clear what the scope of the CoglBitmap api is so it has became a bit of
a dumping ground. CoglBitmap is used for image loading, as a means to
represent the layout of image data and also internally deals with format
conversions.
Note: Because we are avoiding including CoglBitmap as part of the 2.0
API these functions aren't currently included in the 2.0 reference
manual.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
There are many places in the texture backend that need to do
conversion using the CoglBitmap code. Currently none of these
functions can throw an error but they do return a value to indicate
failure. In future it would make sense if new texture functions could
throw an error and in that case they would want to use a CoglBitmap
error if the failure was due to the conversion. This moves the
internal CoglBitmap error from the quartz backend to be public in
cogl-bitmap.h so that it can be used in this way.
This replaces the use of CoglHandle with strongly type CoglBitmap *
pointers instead. The only function not converted for now is
cogl_is_bitmap which will be done in a later commit.
Since using addresses that might change is something that finally
the FSF acknowledge as a plausible scenario (after changing address
twice), the license blurb in the source files should use the URI
for getting the license in case the library did not come with it.
Not that URIs cannot possibly change, but at least it's easier to
set up a redirection at the same place.
As a side note: this commit closes the oldes bug in Clutter's bug
report tool.
http://bugzilla.openedhand.com/show_bug.cgi?id=521
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
• Use the same style for the Cogl API reference as the one used for
the Clutter API reference.
• Fix the introspection annotations for cogl_bitmap_get_size_from_file()
As part of an incremental process to have Cogl be a standalone project we
want to re-consider how we organise the Cogl source code.
Currently this is the structure I'm aiming for:
cogl/
cogl/
<put common source here>
winsys/
cogl-glx.c
cogl-wgl.c
driver/
gl/
gles/
os/ ?
utils/
cogl-fixed
cogl-matrix-stack?
cogl-journal?
cogl-primitives?
pango/
The new winsys component is a starting point for migrating window system
code (i.e. x11,glx,wgl,osx,egl etc) from Clutter to Cogl.
The utils/ and pango/ directories aren't added by this commit, but they are
noted because I plan to add them soon.
Overview of the planned structure:
* The winsys/ API is the API that binds OpenGL to a specific window system,
be that X11 or win32 etc. Example are glx, wgl and egl. Much of the logic
under clutter/{glx,osx,win32 etc} should migrate here.
* Note there is also the idea of a winsys-base that may represent a window
system for which there are multiple winsys APIs. An example of this is
x11, since glx and egl may both be used with x11. (currently only Clutter
has the idea of a winsys-base)
* The driver/ represents a specific varient of OpenGL. Currently we have "gl"
representing OpenGL 1.4-2.1 (mostly fixed function) and "gles" representing
GLES 1.1 (fixed funciton) and 2.0 (fully shader based)
* Everything under cogl/ should fundamentally be supporting access to the
GPU. Essentially Cogl's most basic requirement is to provide a nice GPU
Graphics API and drawing a line between this and the utility functionality
we add to support Clutter should help keep this lean and maintainable.
* Code under utils/ as suggested builds on cogl/ adding more convenient
APIs or mechanism to optimize special cases. Broadly speaking you can
compare cogl/ to OpenGL and utils/ to GLU.
* clutter/pango will be moved to clutter/cogl/pango
How some of the internal configure.ac/pkg-config terminology has changed:
backendextra -> CLUTTER_WINSYS_BASE # e.g. "x11"
backendextralib -> CLUTTER_WINSYS_BASE_LIB # e.g. "x11/libclutter-x11.la"
clutterbackend -> {CLUTTER,COGL}_WINSYS # e.g. "glx"
CLUTTER_FLAVOUR -> {CLUTTER,COGL}_WINSYS
clutterbackendlib -> CLUTTER_WINSYS_LIB
CLUTTER_COGL -> COGL_DRIVER # e.g. "gl"
Note: The CLUTTER_FLAVOUR and CLUTTER_COGL defines are kept for apps
As the first thing to take advantage of the new winsys component in Cogl;
cogl_get_proc_address() has been moved from cogl/{gl,gles}/cogl.c into
cogl/common/cogl.c and this common implementation first trys
_cogl_winsys_get_proc_address() but if that fails then it falls back to
gmodule.
