Commit Graph

10 Commits

Author SHA1 Message Date
Damien Lespiau
e4ca3cb039 doc: s/Fuction/Function/
(cherry picked from commit 8e62a12cff9ba0a267d199c359fdc8e591f65264)
2013-01-22 17:48:12 +00:00
Neil Roberts
4f6fe6f0e2 Fixes for --disable-glib
This fixes some problems which were stopping --disable-glib from
working properly:

• A lot of the public headers were including glib.h. This shouldn't be
  necessary because the API doesn't expose any glib types. Otherwise
  any apps would require glib in order to get the header.

• The public headers were using G_BEGIN_DECLS. There is now a
  replacement macro called COGL_BEGIN_DECLS which is defined in
  cogl-types.h.

• A similar fix has been done for G_GNUC_NULL_TERMINATED and
  G_GNUC_DEPRECATED.

• The CFLAGS were not including $(builddir)/deps/glib which was
  preventing it finding the generated glibconfig.h when building out
  of tree.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit 4138b3141c2f39cddaea3d72bfc04342ed5092d0)
2013-01-22 17:48:05 +00:00
Tomeu Vizoso
93d0de1d9a Mass rename CLUTTER_COMPILATION to COGL_COMPILATION
Reviewed-by: Neil Roberts <neil@linux.intel.com>

(cherry picked from commit a99512e5798e48ffa3a9a1a7eb98bc55647ee1b6)
2012-08-06 14:27:45 +01:00
Robert Bragg
54735dec84 Switch use of primitive glib types to c99 equivalents
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)
2012-08-06 14:27:39 +01:00
Robert Bragg
13c36fff0d offscreen: Replace use of CoglHandle with CoglOffscreen
This updates cogl_offscreen_new_to_texture to return a CoglOffscreen
pointer instead of a CoglHandle.

Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-21 12:38:10 +00:00
Robert Bragg
4c3dadd35e Add a strong CoglTexture type to replace CoglHandle
As part of the on going, incremental effort to purge the non type safe
CoglHandle type from the Cogl API this patch tackles most of the
CoglHandle uses relating to textures.

We'd postponed making this change for quite a while because we wanted to
have a clearer understanding of how we wanted to evolve the texture APIs
towards Cogl 2.0 before exposing type safety here which would be
difficult to change later since it would imply breaking APIs.

The basic idea that we are steering towards now is that CoglTexture
can be considered to be the most primitive interface we have for any
object representing a texture. The texture interface would provide
roughly these methods:

  cogl_texture_get_width
  cogl_texture_get_height
  cogl_texture_can_repeat
  cogl_texture_can_mipmap
  cogl_texture_generate_mipmap;
  cogl_texture_get_format
  cogl_texture_set_region
  cogl_texture_get_region

Besides the texture interface we will then start to expose types
corresponding to specific texture types: CoglTexture2D,
CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and
CoglTexturePixmapX11.

We will then also expose an interface for the high-level texture types
we have (such as CoglTexture2DSlice, CoglSubTexture and
CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an
additional interface that lets you iterate a virtual region of a meta
texture and get mappings of primitive textures to sub-regions of that
virtual region. Internally we already have this kind of abstraction for
dealing with sliced texture, sub-textures and atlas textures in a
consistent way, so this will just make that abstraction public. The aim
here is to clarify that there is a difference between primitive textures
(CoglTexture2D/3D) and some of the other high-level textures, and also
enable developers to implement primitives that can support meta textures
since they can only be used with the cogl_rectangle API currently.

The thing that's not so clean-cut with this are the texture constructors
we have currently; such as cogl_texture_new_from_file which no longer
make sense when CoglTexture is considered to be an interface.  These
will basically just become convenient factory functions and it's just a
bit unusual that they are within the cogl_texture namespace.  It's worth
noting here that all the texture type APIs will also have their own type
specific constructors so these functions will only be used for the
convenience of being able to create a texture without really wanting to
know the details of what type of texture you need.  Longer term for 2.0
we may come up with replacement names for these factory functions or the
other thing we are considering is designing some asynchronous factory
functions instead since it's so often detrimental to application
performance to be blocked waiting for a texture to be uploaded to the
GPU.

Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-09-21 15:27:03 +01:00
Emmanuele Bassi
6b5934a18e Add some more introspection annotations 2010-09-06 16:11:46 +01:00
Emmanuele Bassi
72f4ddf532 Remove mentions of the FSF address
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
2010-03-01 12:56:10 +00:00
Robert Bragg
7fee8a309b cogl_offscreen: deprecate cogl_offscreen_ref/unref.
New code should use cogl_handle_ref/unref
2009-11-26 19:33:13 +00:00
Robert Bragg
0bce7eac53 Intial Re-layout of the Cogl source code and introduction of a Cogl Winsys
As part of an incremental process to have Cogl be a standalone project we
want to re-consider how we organise the Cogl source code.

Currently this is the structure I'm aiming for:
cogl/
    cogl/
	<put common source here>
	winsys/
	   cogl-glx.c
	   cogl-wgl.c
	driver/
	    gl/
	    gles/
	os/ ?
    utils/
	cogl-fixed
	cogl-matrix-stack?
        cogl-journal?
        cogl-primitives?
    pango/

The new winsys component is a starting point for migrating window system
code (i.e.  x11,glx,wgl,osx,egl etc) from Clutter to Cogl.

The utils/ and pango/ directories aren't added by this commit, but they are
noted because I plan to add them soon.

Overview of the planned structure:

* The winsys/ API is the API that binds OpenGL to a specific window system,
  be that X11 or win32 etc.  Example are glx, wgl and egl. Much of the logic
  under clutter/{glx,osx,win32 etc} should migrate here.

* Note there is also the idea of a winsys-base that may represent a window
  system for which there are multiple winsys APIs.  An example of this is
  x11, since glx and egl may both be used with x11.  (currently only Clutter
  has the idea of a winsys-base)

* The driver/ represents a specific varient of OpenGL. Currently we have "gl"
  representing OpenGL 1.4-2.1 (mostly fixed function) and "gles" representing
  GLES 1.1 (fixed funciton) and 2.0 (fully shader based)

* Everything under cogl/ should fundamentally be supporting access to the
  GPU.  Essentially Cogl's most basic requirement is to provide a nice GPU
  Graphics API and drawing a line between this and the utility functionality
  we add to support Clutter should help keep this lean and maintainable.

* Code under utils/ as suggested builds on cogl/ adding more convenient
  APIs or mechanism to optimize special cases. Broadly speaking you can
  compare cogl/ to OpenGL and utils/ to GLU.

* clutter/pango will be moved to clutter/cogl/pango

How some of the internal configure.ac/pkg-config terminology has changed:
backendextra -> CLUTTER_WINSYS_BASE # e.g. "x11"
backendextralib -> CLUTTER_WINSYS_BASE_LIB # e.g. "x11/libclutter-x11.la"
clutterbackend -> {CLUTTER,COGL}_WINSYS # e.g. "glx"
CLUTTER_FLAVOUR -> {CLUTTER,COGL}_WINSYS
clutterbackendlib -> CLUTTER_WINSYS_LIB
CLUTTER_COGL -> COGL_DRIVER # e.g. "gl"

Note: The CLUTTER_FLAVOUR and CLUTTER_COGL defines are kept for apps

As the first thing to take advantage of the new winsys component in Cogl;
cogl_get_proc_address() has been moved from cogl/{gl,gles}/cogl.c into
cogl/common/cogl.c and this common implementation first trys
_cogl_winsys_get_proc_address() but if that fails then it falls back to
gmodule.
2009-10-16 18:58:50 +01:00