Commit Graph

2472 Commits

Author SHA1 Message Date
Robert Bragg
bb3a008318 [draw-buffers] First pass at overhauling Cogl's framebuffer management
Cogl's support for offscreen rendering was originally written just to support
the clutter_texture_new_from_actor API and due to lack of documentation and
several confusing - non orthogonal - side effects of using the API it wasn't
really possible to use directly.

This commit does a number of things:
- It removes {gl,gles}/cogl-fbo.{c,h} and adds shared cogl-draw-buffer.{c,h}
  files instead which should be easier to maintain.
- internally CoglFbo objects are now called CoglDrawBuffers. A
  CoglDrawBuffer is an abstract base class that is inherited from to
  implement CoglOnscreen and CoglOffscreen draw buffers.  CoglOffscreen draw
  buffers will initially be used to support the
  cogl_offscreen_new_to_texture API, and CoglOnscreen draw buffers will
  start to be used internally to represent windows as we aim to migrate some
  of Clutter's backend code to Cogl.
- It makes draw buffer objects the owners of the following state:
  - viewport
  - projection matrix stack
  - modelview matrix stack
  - clip state
(This means when you switch between draw buffers you will automatically be
 switching to their associated viewport, matrix and clip state)

Aside from hopefully making cogl_offscreen_new_to_texture be more useful
short term by having simpler and well defined semantics for
cogl_set_draw_buffer, as mentioned above this is the first step for a couple
of other things:
- Its a step toward moving ownership for windows down from Clutter backends
  into Cogl, by (internally at least) introducing the CoglOnscreen draw
  buffer.  Note: the plan is that cogl_set_draw_buffer will accept on or
  offscreen draw buffer handles, and the "target" argument will become
  redundant since we will instead query the type of the given draw buffer
  handle.
- Because we have a common type for on and offscreen framebuffers we can
  provide a unified API for framebuffer management. Things like:
  - blitting between buffers
  - managing ancillary buffers (e.g. attaching depth and stencil buffers)
  - size requisition
  - clearing
2009-11-03 17:23:03 +00:00
Robert Bragg
6b2ff320ca [cogl-fbo] Bring the gles code more in line with gl code
Over time the two cogl-fbo.c files have needlessly diverged as bug fixes or
cleanups went into one version but not the other.  This tries to bring them
back in line with each other.  It should actually be simple enough to move
cogl-fbo.c to be a common file, and simply not build it for GLES 1.1, so
maybe I'll follow up with such a patch soon.
2009-11-02 16:55:02 +00:00
Robert Bragg
cc0af441f2 [cogl-fbo] Remove poorly documented workaround for unknown driver/hardware
The comment just said: "Some implementation require a clear before drawing
to an fbo.  Luckily it is affected by scissor test." and did a scissored
clear, which is clearly a driver bug workaround, but for what driver?  The
fact that it was copied into the gles backend (or vica versa is also
suspicious since it seems unlikely that the workaround is necessary for both
backends.)

We can easily restore the workaround with a better comment if this problem
really still exists on current drivers, but for now I'd rather minimize
hand-wavey workaround code that can't be tested.
2009-11-02 16:55:02 +00:00
Emmanuele Bassi
df920a42df build: Add missing gles/cogl-context-driver.h to dist
The gles/cogl-context-driver.h header file is missing from the
dist target, which means it's not in the tarballs.
2009-10-30 12:11:19 +00:00
Neil Roberts
435d415a45 [cogl_polygon] Enable COGL_ENABLE_BLEND when use_color is set
Otherwise you can't use the alpha channel of the vertex colors unless
the material has a texture with alpha or the material's color has
alpha less than 255.
2009-10-27 13:18:51 +00:00
Neil Roberts
67a896e5df build: Add $(top_buiddir)/clutter/cogl to the include path in clutter/cogl/cogl
Some files try to include "cogl/cogl-defines-gl.h" so
$(top_builddir)/clutter/cogl needs to be in the include path for out of
tree builds to work.
2009-10-27 12:53:57 +00:00
Emmanuele Bassi
be06fe0b75 cogl: Avoid C99-isms
Do not declare variables after statements.
2009-10-23 16:44:28 +01:00
Emmanuele Bassi
edeca915cd cogl: Remove cogl-current-matrix.c
The cogl-current-matrix.c file is unused since commit
5e5d94dfbe and it's not compiled
or distributed anymore.
2009-10-23 15:46:25 +01:00
Emmanuele Bassi
fcce833606 build: Make COGL pass distcheck
Some changes to make COGL pass distcheck with Automake 1.11 and
anal-retentiveness turned up to 11.

The "major" change is the flattening of the winsys/ part of COGL,
which is built directly inside libclutter-cogl.la instead of an
intermediate libclutter-cogl-winsys.la object.

Ideally, the whole COGL should be flattened out using a
quasi-non-recursive Automake layout; unfortunately, the driver/
sub-section ships with identical targets and Automake cannot
distinguish GL and GLES objects.
2009-10-23 13:38:40 +01:00
Neil Roberts
6cff24f437 Fix some compilation errors in cogl-gles2-wrapper.c
The changes in 74f2122b6 introduced some syntax errors which were
preventing the GLES2 backend from compiling.
2009-10-22 18:04:59 +01:00
Robert Bragg
c02e10c688 [gles2] remove lots of redundant matrix stack code
Since we no longer depend on the GL matrix API in Cogl we can remove a lot
of wrapper code from the GLES 2 backend.  This is particularly nice given
that there was no code shared between the cogl-matrix-stack API and gles2
wrappers so we had a lot of duplicated logic.
2009-10-20 12:32:51 +01:00
Robert Bragg
eed2479556 [cogl] Removes the cogl-current-matrix abstraction
The indirection through this API isn't necessary since we no longer
arbitrate between the OpenGL matrix API and Cogl's client side API.  Also it
doesn't help to maintain an OpenGL style matrix mode API for internal use
since it's awkward to keep restoring the MODELVIEW mode and easy enough to
directly work with the matrix stacks of interest.

This replaces use of the _cogl_current_matrix API with direct use of the
_cogl_matrix_stack API.  All the unused cogl_current_matrix API is removed
and the matrix utility code left in cogl-current-matrix.c was moved to
cogl.c.
2009-10-20 12:32:50 +01:00
Robert Bragg
01887460f6 [matrix-stack] Adds ctx->flushed_matrix_mode to cache the gl matrix mode
This cache of the gl matrix mode lets us avoid repeat calls to glMatrixMode
in _cogl_matrix_stack_flush_to_gl when we have lots of sequential modelview
matrix modifications.
2009-10-20 12:32:50 +01:00
Robert Bragg
43f8032a7f matrix-stack: more optimization for load_identity case
This goes a bit further than the previous patch, and as a special case
we now simply represent identity matrices using a boolean, and only
lazily initialize them when they need to be modified.
2009-10-20 12:32:50 +01:00
Robert Bragg
d153316045 [matrix-stack] avoid redundant clearing of matrix when using load_identity
The journal always uses an identity matrix since it uses software
transformation.  Currently it manually uses glLoadMatrix since previous
experimentation showed that the cogl-matrix-stack gave bad performance, but
it would be nice to fix performance so we only have to care about one path
for loading matrices.

For the common case where we do:
cogl_matrix_stack_push()
cogl_matrix_stack_load_identity()
we were effectively initializing the matrix 3 times. Once due to use of
g_slice_new0, then we had a cogl_matrix_init_identity in
_cogl_matrix_state_new for good measure, and then finally in
cogl_matrix_stack_load_identity we did another cogl_matrix_init_identity.

We don't use g_slice_new0 anymore, _cogl_matrix_state_new is documented as
not initializing the matrix (instead _cogl_matrix_stack_top_mutable now
takes a boolean to choose if new stack entries should be initialised) and so
we now only initialize once in cogl_matrix_stack_load_identity.
2009-10-20 12:32:49 +01:00
Robert Bragg
1402d1eb3c [current-matrix] Adds texture matrix stacks + removes GL matrix API usage
This relates back to an earlier commitment to stop using the OpenGL matrix
API which is considered deprecated. (ref 54159f5a1d)

The new texture matrix stacks are hung from a list of (internal only)
CoglTextureUnit structures which the CoglMaterial code internally references
via _cogl_get_texure_unit ().

So we would be left with only the cogl-matrix-stack code being responsible
for glMatrixMode, glLoadMatrix and glLoadIdentity this commit updates the
journal code so it now uses the matrix-stack API instead of GL directly.
2009-10-20 12:32:45 +01:00
Robert Bragg
861766f4ad [cogl-primitives] Split the journal out from cogl-primitives.c
The Journal can be considered a standalone component, so even though
it's currently only used to log quads, it seems better to split it
out into its own file.
2009-10-16 18:58:52 +01:00
Robert Bragg
5387aa0e9e [cogl-spans] split out cogl-spans code from cogl-texture-2d-sliced
When we implement atlas textures we will probably want to use the spans API
to handle texture repeating so it doesn't make sense to leave the code in
cogl-texture-2d-sliced.c.  Since it's a standalone set of data structures
and algorithms it also seems reasonable to split out from cogl-texture.
2009-10-16 18:58:52 +01:00
Vladimir Nadvornik
65015a137e [cogl-texture] Split CoglTexture into an abstract class + CoglTexture2dSliced
cogl-texture-2d-sliced provides an implementation of CoglTexture and this
seperation lays the foundation for potentially supporting atlas textures,
pixmap textures (as in GLX_EXT_texture_from_pixmap) and fast-path
GL_TEXTURE_{1D,2D,3D,RECTANGLE} textures in a maintainable fashion.
2009-10-16 18:58:51 +01:00
Robert Bragg
c40d5ae9ea [cogl-texture] Seal CoglTexture internals from cogl-primitives.c
cogl-primitives.c was previously digging right into CoglTextures so it could
manually iterate the texture slices for texturing quads and polygons and
because we were missing some state getters we were lazily just poking into
the structures directly.

This adds some extra state getter functions, and adds a higher level
_cogl_texture_foreach_slice () API that hopefully simplifies the way in
which sliced textures may be used to render primitives.  This lets you
specify a rectangle in "virtual" texture coords and it will call a given
callback for each slice that intersects that rectangle giving the virtual
coords of the current slice and corresponding "real" texture coordinates for
the underlying gl texture.

At the same time a noteable bug in how we previously iterated sliced
textures was fixed, whereby we weren't correctly handling inverted texture
coordinates.  E.g.  with the previous code if you supplied texture coords of
tx1=100,ty1=0,tx2=0,ty2=100 (inverted along y axis) that would result in a
back-facing quad, which could be discarded if using back-face culling.
2009-10-16 18:58:51 +01:00
Robert Bragg
c943b34cbe [docs] switch gl_handle+gl_target docs for cogl_texture_new_from_foreign
The descriptions for gl_handle and gl_target were inverted.

Thanks to Young-Ho Cha for spotting that.

Signed-off-by: Robert Bragg <robert@linux.intel.com>
2009-10-16 18:58:51 +01: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