Commit Graph

10 Commits

Author SHA1 Message Date
Robert Bragg
b4770c1e9b [cogl] Make sure Cogl always knows the current window geometry
Because Cogl defines the origin of viewport and window coordinates to be
top-left it always needs to know the size of the current window so that Cogl
window/viewport coordinates can be transformed into OpenGL coordinates.

This also fixes cogl_read_pixels to use the current draw buffer height
instead of the viewport height to determine the OpenGL y coordinate to use
for glReadPixels.
2009-11-04 03:23:20 +00:00
Robert Bragg
2d610c2300 [cogl] Make sure we draw upside down to offscreen draw buffers
First a few notes about Cogl coordinate systems:
- Cogl defines the window origin, viewport origin and texture coordinates
origin to be top left unlike OpenGL which defines them as bottom left.
- Cogl defines the modelview and projection identity matrices in exactly the
same way as OpenGL.
- I.e. we believe that for 2D centric constructs: windows/framebuffers,
viewports and textures developers are more used to dealing with a top left
origin, but when modeling objects in 3D; an origin at the center with y
going up is quite natural.

The way Cogl handles textures is by uploading data upside down in OpenGL
terms so that bottom left becomes top left.  (Note: This also has the
benefit that we don't need to flip the data we get from image decoding
libraries since they typically also consider top left to be the image
origin.)

The viewport and window coords are mostly handled with various y =
height - y tweaks before we pass y coordinates to OpenGL.

Generally speaking though the handling of coordinate spaces in Cogl is a bit
fragile.  I guess partly because none of it was design to be, it just
evolved from how Clutter defines its coordinates without much consideration
or testing.  I hope to improve this over a number of commits; starting here.

This commit deals with the fact that offscreen draw buffers may be bound to
textures but we don't "upload" the texture data upside down, and so if you
texture from an offscreen draw buffer you need to manually flip the texture
coordinates to get it the right way around.  We now force offscreen
rendering to be flipped upside down by tweaking the projection matrix right
before we submit it to OpenGL to scale y by -1.  The tweak is entirely
hidden from the user such that if you call cogl_get_projection you will not
see this scale.
2009-11-04 03:23:19 +00:00
Robert Bragg
4bc947cfcc [cogl] Ensure features are initialized first in cogl_create_context
Previously some context initializing was being done without valid feature
flags.
2009-11-04 03:23:19 +00:00
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
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
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
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
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