Go to file
Neil Roberts d69d49fada pipeline: Unify how the backends store private data
Previously the fragends had a separate private data pointer which was
used by the GLSL and ARBfp fragends to store a tiny struct containing
a single pointer to the ref-counted shader state. The space for the
private data pointer is reserved in all of the pipelines for all of
the potential backends. The vertends and progends however did this
differently by directly storing the pointer to the ref counted data
using cogl_object_set_user_data. This patch unifies the different
methods so that they all use cogl_object_set_user_data and the
fragends don't bother with the separate tiny allocation for the
private data. The private data pointer array has been removed from
CoglPipeline and the corresponding fragend virtual to free the private
data has also been removed because this can instead be done with the
destroy notify from the object user data.

The variable names used have been unified so that all of the vertends
and fragends name their data struct CoglPipelineShaderState and use a
variable called shader_state to refer to it. The progend uses
CoglPipelineProgramState and a variable called program_state.

This should also fix two potential bugs. the ARBfp fragend was
apprently leaking a reference to the private state when it creates the
private data because it was adding a reference before stroring the
pointer to the newly allocated data but the ref count is already set
to 1 on creation. The other potential bug is that the free function
for CoglPipeline was only calling the free_priv virtual for the
currently used fragend of the pipeline. The design of the fragends is
meant to allow a pipeline to have multiple fragend priv datas because
a child pipeline could be attaching its fragend data to the ancestor
and its allowed to pick a different fragend.
2011-07-13 12:30:07 +01:00
build releasing: Fix the check for an even micro version number 2011-07-01 16:47:42 +01:00
cogl pipeline: Unify how the backends store private data 2011-07-13 12:30:07 +01:00
cogl-pango Dynamically load the GL or GLES library 2011-07-11 12:57:38 +01:00
doc dist: give 2.0 manual unique DOC_MODULE name 2011-07-11 15:40:02 +01:00
examples Remove cogl_context_set_default API 2011-07-11 14:07:02 +01:00
po Added Japanese translation. 2011-07-03 19:26:42 +09:00
.gitignore Adds examples/crate to .gitignore 2011-07-11 15:40:01 +01:00
.vimrc misc: Add a .vimrc file 2011-05-17 15:24:54 +01:00
autogen.sh build: Allow to compile a git checkout without gtk-doc 2011-05-12 11:45:25 +01:00
cogl.doap Adds an initial cogl.doap file 2011-05-06 12:12:13 +01:00
config-custom.h configure: Force #undef of 'near' and 'far' on Windows 2011-06-14 12:14:02 +01:00
configure.ac build: Fix the help string for --enable-profile 2011-07-12 10:39:20 +01:00
COPYING Adds a COPYING file 2011-05-05 21:27:11 +01:00
Makefile.am Ensure we use --enable-profile during make distcheck 2011-06-14 17:09:56 +01:00
NEWS NEWS: Update for the 1.7.2 release 2011-07-01 16:47:42 +01:00
README.in README: Fix a tiny typo 2011-07-04 14:37:11 +01:00

README for Cogl @COGL_VERSION@
===============================================================================

Note: This file is delimited with -- markers so it is possible to split
sections out for other purposes, such as for release notes.

--
DESCRIPTION
-------------------------------------------------------------------------------

Cogl is a small open source library for using 3D graphics hardware to draw
pretty pictures. The API departs from the flat state machine style of
OpenGL and is designed to make it easy to write orthogonal components that
can render without stepping on each others toes.

As well as aiming for a nice API, we think having a single library as opposed
to an API specification like OpenGL has a few advantages too; like being
able to paper over the inconsistencies/bugs of different OpenGL
implementations in a centralized place, not to mention the myriad of OpenGL
extensions. It also means we are in a better position to provide utility
APIs that help software developers since they only need to be implemented
once and there is no risk of inconsistency between implementations.

Having other backends, besides OpenGL, such as drm, Gallium or D3D are
options we are interested in for the future.

--
REQUIREMENTS
-------------------------------------------------------------------------------

Cogl currently only requires:

  • GLib ≥ @GLIB_REQ_VERSION@
  • OpenGL ≥ 1.3 (or 1.2 + multitexturing), or OpenGL ES 2.0 (or 1.1)
  • GLX, AGL, WGL or an EGL implementation

Cogl also has optional dependencies:

  • GDK-Pixbuf ≥ @GDK_PIXBUF_REQ_VERSION@
     - for image loading
  • Cairo ≥ @CAIRO_REQ_VERSION@
     - for debugging texture atlasing (debug builds only)

The optional Cogl Pango library requires:
  • Cairo ≥ @CAIRO_REQ_VERSION@
  • PangoCairo ≥ @PANGOCAIRO_REQ_VERSION@

On X11, Cogl depends on the following extensions

  • XComposite ≥ @XCOMPOSITE_REQ_VERSION@
  • XDamage
  • XExt
  • XFixes ≥ @XFIXES_REQ_VERSION@

When running with OpenGL, Cogl requires at least version 1.3
or 1.2 with the multitexturing extension. However to build Cogl
you will need the latest GL headers which can be obtained from:

  http://www.khronos.org

If you are building the API reference you will also need:

  • GTK-Doc ≥ @GTK_DOC_REQ_VERSION@

If you are building the additional documentation you will also need:

  • xsltproc
  • jw (optional, for generating PDFs)

If you are building the Introspection data you will also need:

  • GObject-Introspection ≥ @GI_REQ_VERSION@

GObject-Introspection is available from:

  git://git.gnome.org/gobject-introspection

If you want support for profiling Cogl you will also need:

  • UProf ≥ @UPROF_REQ_VERSION@

UProf is available from:

  git://github.com/rib/UProf.git

--
DOCUMENTATION
-------------------------------------------------------------------------------

The API references for the latest stable release are available at:

   http://docs.clutter-project.org/docs/cogl/stable/

The experimental 2.0 API can be found here:

   http://docs.clutter-project.org/docs/cogl-2.0-experimental/stable/

   Note: The conflicting "stable" at the end refers to the fact
   to overall Cogl release status, not the documentation specifically.

--
LICENSE
-------------------------------------------------------------------------------

Most of Cogl is licensed under the terms of the GNU Lesser General Public
License, version 2.1 or (at your option) later. Some files are licensed under
more permissive licenses MIT or BSD style licenses though so please see
individual files for details.

--
BUILDING AND INSTALLATION
-------------------------------------------------------------------------------

Please refer to the INSTALL document.

--
BUGS
-------------------------------------------------------------------------------

Please report bugs here:

  http://bugzilla.gnome.org/enter_bug.cgi?product=clutter

You will need a Bugzilla account.

Please include the following in bug reports:

  • what system you're running Cogl on;
  • which version of Cogl you are using;
  • which version of GLib and OpenGL (or OpenGL ES) you are using;
  • which video card and which drivers you are using, including output of
    glxinfo and xdpyinfo (if applicable);
  • how to reproduce the bug.

If you cannot reproduce the bug with one of the tests that come with
Cogl's source code, it can help a lot to include a small test case
displaying the bad behaviour.

If the bug exposes a crash, the exact text printed out and a stack trace
obtained using gdb are greatly appreciated.

--
CONTRIBUTING
-------------------------------------------------------------------------------

The CODING_STYLE file describes the coding style we use throughout Cogl,
please try your best to conform to this style because the consistency
really helps keep the code maintainable.

We can accept contributions in several ways:
  • Either as patches attached to bugs on bugzilla
      - For this you may be interested in using git-bz.

        See http://git.fishsoup.net/man/git-bz.html for details
  • You can email us patches
      - For this we recommend using git-send-email

  • You can create a remote branch and ask us to pull from that for more
    substantial changes.
      - For this we recommend using github.

Ideally standalone patches should be created using git format-patch since
that makes it easiest to import the patch with a commit message into a
git repository.