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
2011-09-21 09:33:03 +02:00
2011-09-19 16:40:07 +01:00
2011-05-17 15:24:54 +01:00
2011-05-06 12:12:13 +01:00
2011-09-19 19:52:13 +01:00
2011-09-05 19:02:05 +01:00
2011-09-19 19:19:35 +01:00

README for Cogl @COGL_1_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 for
rendering. 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 confusing "stable" at the end refers to the 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=cogl

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.
Description
Languages
C 98.9%
Meson 0.7%
Python 0.3%