2009-03-30 12:07:31 -04:00
|
|
|
/*
|
|
|
|
* Cogl
|
|
|
|
*
|
2014-02-21 20:28:54 -05:00
|
|
|
* A Low Level GPU Graphics and Utilities API
|
2009-03-30 12:07:31 -04:00
|
|
|
*
|
2010-03-19 05:55:30 -04:00
|
|
|
* Copyright (C) 2007,2008,2009,2010 Intel Corporation.
|
2009-03-30 12:07:31 -04:00
|
|
|
*
|
2014-02-21 20:28:54 -05:00
|
|
|
* Permission is hereby granted, free of charge, to any person
|
|
|
|
* obtaining a copy of this software and associated documentation
|
|
|
|
* files (the "Software"), to deal in the Software without
|
|
|
|
* restriction, including without limitation the rights to use, copy,
|
|
|
|
* modify, merge, publish, distribute, sublicense, and/or sell copies
|
|
|
|
* of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
2009-03-30 12:07:31 -04:00
|
|
|
*
|
2014-02-21 20:28:54 -05:00
|
|
|
* The above copyright notice and this permission notice shall be
|
|
|
|
* included in all copies or substantial portions of the Software.
|
2009-03-30 12:07:31 -04:00
|
|
|
*
|
2014-02-21 20:28:54 -05:00
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
2010-03-01 07:56:10 -05:00
|
|
|
*
|
|
|
|
*
|
2009-03-30 12:07:31 -04:00
|
|
|
*/
|
|
|
|
|
2016-05-05 10:21:51 -04:00
|
|
|
#include "cogl-config.h"
|
2009-03-30 12:07:31 -04:00
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
#include <math.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
2013-04-27 21:42:24 -04:00
|
|
|
#include "cogl-i18n-private.h"
|
2009-05-19 09:44:29 -04:00
|
|
|
#include "cogl-debug.h"
|
2020-09-11 14:14:26 -04:00
|
|
|
#include "cogl-graphene.h"
|
2009-03-30 12:07:31 -04:00
|
|
|
#include "cogl-util.h"
|
2010-11-04 18:25:52 -04:00
|
|
|
#include "cogl-context-private.h"
|
2010-10-27 13:54:57 -04:00
|
|
|
#include "cogl-pipeline-private.h"
|
2009-11-26 14:06:35 -05:00
|
|
|
#include "cogl-framebuffer-private.h"
|
2010-01-22 13:14:57 -05:00
|
|
|
#include "cogl-journal-private.h"
|
2010-03-01 13:08:41 -05:00
|
|
|
#include "cogl-bitmap-private.h"
|
|
|
|
#include "cogl-texture-private.h"
|
|
|
|
#include "cogl-texture-driver.h"
|
2011-01-20 14:31:53 -05:00
|
|
|
#include "cogl-attribute-private.h"
|
2011-01-05 10:30:04 -05:00
|
|
|
#include "cogl-framebuffer-private.h"
|
2011-07-27 07:30:02 -04:00
|
|
|
#include "cogl-renderer-private.h"
|
2011-09-14 07:17:09 -04:00
|
|
|
#include "cogl-private.h"
|
2012-02-17 16:46:39 -05:00
|
|
|
#include "cogl1-context.h"
|
2012-02-17 20:19:17 -05:00
|
|
|
#include "cogl-offscreen.h"
|
2018-05-21 15:57:38 -04:00
|
|
|
#include "winsys/cogl-winsys-private.h"
|
2009-03-30 12:07:31 -04:00
|
|
|
|
2018-11-30 09:04:45 -05:00
|
|
|
GCallback
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
cogl_get_proc_address (const char* name)
|
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-07-27 21:02:02 -04:00
|
|
|
{
|
2011-02-25 06:29:08 -05:00
|
|
|
_COGL_GET_CONTEXT (ctx, NULL);
|
|
|
|
|
2012-06-20 07:42:31 -04:00
|
|
|
return _cogl_renderer_get_proc_address (ctx->display->renderer, name, FALSE);
|
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-07-27 21:02:02 -04:00
|
|
|
}
|
|
|
|
|
2018-11-24 07:04:47 -05:00
|
|
|
gboolean
|
2012-09-26 15:32:36 -04:00
|
|
|
_cogl_check_extension (const char *name, char * const *ext)
|
2010-02-05 11:32:19 -05:00
|
|
|
{
|
2012-09-26 15:32:36 -04:00
|
|
|
while (*ext)
|
|
|
|
if (!strcmp (name, *ext))
|
|
|
|
return TRUE;
|
|
|
|
else
|
|
|
|
ext++;
|
2010-02-05 11:32:19 -05:00
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2010-05-26 06:33:32 -04:00
|
|
|
/* XXX: This API has been deprecated */
|
2009-03-30 12:07:31 -04:00
|
|
|
void
|
2018-11-24 07:04:47 -05:00
|
|
|
cogl_set_depth_test_enabled (gboolean setting)
|
2009-03-30 12:07:31 -04:00
|
|
|
{
|
2010-05-26 06:33:32 -04:00
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
Previously the journal was always flushed at the end of
_cogl_rectangles_with_multitexture_coords, (i.e. the end of any
cogl_rectangle* calls) but now we have broadened the potential for batching
geometry. In ideal circumstances we will only flush once per scene.
In summary the journal works like this:
When you use any of the cogl_rectangle* APIs then nothing is emitted to the
GPU at this point, we just log one or more quads into the journal. A
journal entry consists of the quad coordinates, an associated material
reference, and a modelview matrix. Ideally the journal only gets flushed
once at the end of a scene, but in fact there are things to consider that
may cause unwanted flushing, including:
- modifying materials mid-scene
This is because each quad in the journal has an associated material
reference (i.e. not copy), so if you try and modify a material that is
already referenced in the journal we force a flush first)
NOTE: For now this means you should avoid using cogl_set_source_color()
since that currently uses a single shared material. Later we
should change it to use a pool of materials that is recycled
when the journal is flushed.
- modifying any state that isn't currently logged, such as depth, fog and
backface culling enables.
The first thing that happens when flushing, is to upload all the vertex data
associated with the journal into a single VBO.
We then go through a process of splitting up the journal into batches that
have compatible state so they can be emitted to the GPU together. This is
currently broken up into 3 levels so we can stagger the state changes:
1) we break the journal up according to changes in the number of material layers
associated with logged quads. The number of layers in a material determines
the stride of the associated vertices, so we have to update our vertex
array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc)
2) we further split batches up according to material compatability. (e.g.
materials with different textures) We flush material state at this level.
3) Finally we split batches up according to modelview changes. At this level
we update the modelview matrix and actually emit the actual draw command.
This commit is largely about putting the initial design in-place; this will be
followed by other changes that take advantage of the extended batching.
2009-06-17 13:46:42 -04:00
|
|
|
|
2010-05-26 06:33:32 -04:00
|
|
|
if (ctx->legacy_depth_test_enabled == setting)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ctx->legacy_depth_test_enabled = setting;
|
2009-05-26 11:55:11 -04:00
|
|
|
}
|
|
|
|
|
2010-05-26 06:33:32 -04:00
|
|
|
/* XXX: This API has been deprecated */
|
2018-11-24 07:04:47 -05:00
|
|
|
gboolean
|
2009-05-26 11:55:11 -04:00
|
|
|
cogl_get_depth_test_enabled (void)
|
|
|
|
{
|
2010-05-26 06:33:32 -04:00
|
|
|
_COGL_GET_CONTEXT (ctx, FALSE);
|
|
|
|
return ctx->legacy_depth_test_enabled;
|
2009-03-30 12:07:31 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2018-11-24 07:04:47 -05:00
|
|
|
cogl_set_backface_culling_enabled (gboolean setting)
|
2009-03-30 12:07:31 -04:00
|
|
|
{
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
2011-09-15 06:25:39 -04:00
|
|
|
if (ctx->legacy_backface_culling_enabled == setting)
|
2009-10-22 14:09:20 -04:00
|
|
|
return;
|
|
|
|
|
2011-09-15 06:25:39 -04:00
|
|
|
ctx->legacy_backface_culling_enabled = setting;
|
2009-03-30 12:07:31 -04:00
|
|
|
}
|
|
|
|
|
2018-11-24 07:04:47 -05:00
|
|
|
gboolean
|
2009-05-26 11:55:11 -04:00
|
|
|
cogl_get_backface_culling_enabled (void)
|
|
|
|
{
|
|
|
|
_COGL_GET_CONTEXT (ctx, FALSE);
|
|
|
|
|
2011-09-15 06:25:39 -04:00
|
|
|
return ctx->legacy_backface_culling_enabled;
|
2009-10-22 14:01:52 -04:00
|
|
|
}
|
|
|
|
|
2018-11-24 07:04:47 -05:00
|
|
|
gboolean
|
2011-10-12 17:31:12 -04:00
|
|
|
cogl_has_feature (CoglContext *ctx, CoglFeatureID feature)
|
|
|
|
{
|
|
|
|
return COGL_FLAGS_GET (ctx->features, feature);
|
|
|
|
}
|
|
|
|
|
2018-11-24 07:04:47 -05:00
|
|
|
gboolean
|
2011-10-12 17:31:12 -04:00
|
|
|
cogl_has_features (CoglContext *ctx, ...)
|
|
|
|
{
|
|
|
|
va_list args;
|
|
|
|
CoglFeatureID feature;
|
|
|
|
|
|
|
|
va_start (args, ctx);
|
|
|
|
while ((feature = va_arg (args, CoglFeatureID)))
|
|
|
|
if (!cogl_has_feature (ctx, feature))
|
|
|
|
return FALSE;
|
|
|
|
va_end (args);
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
cogl_foreach_feature (CoglContext *ctx,
|
|
|
|
CoglFeatureCallback callback,
|
|
|
|
void *user_data)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < _COGL_N_FEATURE_IDS; i++)
|
|
|
|
if (COGL_FLAGS_GET (ctx->features, i))
|
|
|
|
callback (i, user_data);
|
|
|
|
}
|
|
|
|
|
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
Previously the journal was always flushed at the end of
_cogl_rectangles_with_multitexture_coords, (i.e. the end of any
cogl_rectangle* calls) but now we have broadened the potential for batching
geometry. In ideal circumstances we will only flush once per scene.
In summary the journal works like this:
When you use any of the cogl_rectangle* APIs then nothing is emitted to the
GPU at this point, we just log one or more quads into the journal. A
journal entry consists of the quad coordinates, an associated material
reference, and a modelview matrix. Ideally the journal only gets flushed
once at the end of a scene, but in fact there are things to consider that
may cause unwanted flushing, including:
- modifying materials mid-scene
This is because each quad in the journal has an associated material
reference (i.e. not copy), so if you try and modify a material that is
already referenced in the journal we force a flush first)
NOTE: For now this means you should avoid using cogl_set_source_color()
since that currently uses a single shared material. Later we
should change it to use a pool of materials that is recycled
when the journal is flushed.
- modifying any state that isn't currently logged, such as depth, fog and
backface culling enables.
The first thing that happens when flushing, is to upload all the vertex data
associated with the journal into a single VBO.
We then go through a process of splitting up the journal into batches that
have compatible state so they can be emitted to the GPU together. This is
currently broken up into 3 levels so we can stagger the state changes:
1) we break the journal up according to changes in the number of material layers
associated with logged quads. The number of layers in a material determines
the stride of the associated vertices, so we have to update our vertex
array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc)
2) we further split batches up according to material compatability. (e.g.
materials with different textures) We flush material state at this level.
3) Finally we split batches up according to modelview changes. At this level
we update the modelview matrix and actually emit the actual draw command.
This commit is largely about putting the initial design in-place; this will be
followed by other changes that take advantage of the extended batching.
2009-06-17 13:46:42 -04:00
|
|
|
void
|
2009-06-29 12:10:34 -04:00
|
|
|
cogl_flush (void)
|
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
Previously the journal was always flushed at the end of
_cogl_rectangles_with_multitexture_coords, (i.e. the end of any
cogl_rectangle* calls) but now we have broadened the potential for batching
geometry. In ideal circumstances we will only flush once per scene.
In summary the journal works like this:
When you use any of the cogl_rectangle* APIs then nothing is emitted to the
GPU at this point, we just log one or more quads into the journal. A
journal entry consists of the quad coordinates, an associated material
reference, and a modelview matrix. Ideally the journal only gets flushed
once at the end of a scene, but in fact there are things to consider that
may cause unwanted flushing, including:
- modifying materials mid-scene
This is because each quad in the journal has an associated material
reference (i.e. not copy), so if you try and modify a material that is
already referenced in the journal we force a flush first)
NOTE: For now this means you should avoid using cogl_set_source_color()
since that currently uses a single shared material. Later we
should change it to use a pool of materials that is recycled
when the journal is flushed.
- modifying any state that isn't currently logged, such as depth, fog and
backface culling enables.
The first thing that happens when flushing, is to upload all the vertex data
associated with the journal into a single VBO.
We then go through a process of splitting up the journal into batches that
have compatible state so they can be emitted to the GPU together. This is
currently broken up into 3 levels so we can stagger the state changes:
1) we break the journal up according to changes in the number of material layers
associated with logged quads. The number of layers in a material determines
the stride of the associated vertices, so we have to update our vertex
array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc)
2) we further split batches up according to material compatability. (e.g.
materials with different textures) We flush material state at this level.
3) Finally we split batches up according to modelview changes. At this level
we update the modelview matrix and actually emit the actual draw command.
This commit is largely about putting the initial design in-place; this will be
followed by other changes that take advantage of the extended batching.
2009-06-17 13:46:42 -04:00
|
|
|
{
|
2011-01-06 08:25:45 -05:00
|
|
|
GList *l;
|
|
|
|
|
|
|
|
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
|
|
|
|
|
|
|
|
for (l = ctx->framebuffers; l; l = l->next)
|
|
|
|
_cogl_framebuffer_flush_journal (l->data);
|
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
Previously the journal was always flushed at the end of
_cogl_rectangles_with_multitexture_coords, (i.e. the end of any
cogl_rectangle* calls) but now we have broadened the potential for batching
geometry. In ideal circumstances we will only flush once per scene.
In summary the journal works like this:
When you use any of the cogl_rectangle* APIs then nothing is emitted to the
GPU at this point, we just log one or more quads into the journal. A
journal entry consists of the quad coordinates, an associated material
reference, and a modelview matrix. Ideally the journal only gets flushed
once at the end of a scene, but in fact there are things to consider that
may cause unwanted flushing, including:
- modifying materials mid-scene
This is because each quad in the journal has an associated material
reference (i.e. not copy), so if you try and modify a material that is
already referenced in the journal we force a flush first)
NOTE: For now this means you should avoid using cogl_set_source_color()
since that currently uses a single shared material. Later we
should change it to use a pool of materials that is recycled
when the journal is flushed.
- modifying any state that isn't currently logged, such as depth, fog and
backface culling enables.
The first thing that happens when flushing, is to upload all the vertex data
associated with the journal into a single VBO.
We then go through a process of splitting up the journal into batches that
have compatible state so they can be emitted to the GPU together. This is
currently broken up into 3 levels so we can stagger the state changes:
1) we break the journal up according to changes in the number of material layers
associated with logged quads. The number of layers in a material determines
the stride of the associated vertices, so we have to update our vertex
array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc)
2) we further split batches up according to material compatability. (e.g.
materials with different textures) We flush material state at this level.
3) Finally we split batches up according to modelview changes. At this level
we update the modelview matrix and actually emit the actual draw command.
This commit is largely about putting the initial design in-place; this will be
followed by other changes that take advantage of the extended batching.
2009-06-17 13:46:42 -04:00
|
|
|
}
|
|
|
|
|
2012-08-31 14:28:27 -04:00
|
|
|
uint32_t
|
2009-11-11 08:26:54 -05:00
|
|
|
_cogl_driver_error_quark (void)
|
|
|
|
{
|
|
|
|
return g_quark_from_static_string ("cogl-driver-error-quark");
|
|
|
|
}
|
2010-03-19 05:55:30 -04:00
|
|
|
|
2010-04-22 08:48:49 -04:00
|
|
|
/* Scale from OpenGL normalized device coordinates (ranging from -1 to 1)
|
|
|
|
* to Cogl window/framebuffer coordinates (ranging from 0 to buffer-size) with
|
|
|
|
* (0,0) being top left. */
|
|
|
|
#define VIEWPORT_TRANSFORM_X(x, vp_origin_x, vp_width) \
|
|
|
|
( ( ((x) + 1.0) * ((vp_width) / 2.0) ) + (vp_origin_x) )
|
|
|
|
/* Note: for Y we first flip all coordinates around the X axis while in
|
2020-08-26 05:49:50 -04:00
|
|
|
* normalized device coordinates */
|
2010-04-22 08:48:49 -04:00
|
|
|
#define VIEWPORT_TRANSFORM_Y(y, vp_origin_y, vp_height) \
|
|
|
|
( ( ((-(y)) + 1.0) * ((vp_height) / 2.0) ) + (vp_origin_y) )
|
|
|
|
|
|
|
|
/* Transform a homogeneous vertex position from model space to Cogl
|
|
|
|
* window coordinates (with 0,0 being top left) */
|
|
|
|
void
|
2020-09-11 14:57:28 -04:00
|
|
|
_cogl_transform_point (const graphene_matrix_t *matrix_mv,
|
|
|
|
const graphene_matrix_t *matrix_p,
|
|
|
|
const float *viewport,
|
|
|
|
float *x,
|
|
|
|
float *y)
|
2010-04-22 08:48:49 -04:00
|
|
|
{
|
|
|
|
float z = 0;
|
|
|
|
float w = 1;
|
|
|
|
|
|
|
|
/* Apply the modelview matrix transform */
|
2020-09-11 14:14:26 -04:00
|
|
|
cogl_graphene_matrix_project_point (matrix_mv, x, y, &z, &w);
|
2010-04-22 08:48:49 -04:00
|
|
|
|
|
|
|
/* Apply the projection matrix transform */
|
2020-09-11 14:14:26 -04:00
|
|
|
cogl_graphene_matrix_project_point (matrix_p, x, y, &z, &w);
|
2010-04-22 08:48:49 -04:00
|
|
|
|
|
|
|
/* Perform perspective division */
|
|
|
|
*x /= w;
|
|
|
|
*y /= w;
|
|
|
|
|
|
|
|
/* Apply viewport transform */
|
|
|
|
*x = VIEWPORT_TRANSFORM_X (*x, viewport[0], viewport[2]);
|
|
|
|
*y = VIEWPORT_TRANSFORM_Y (*y, viewport[1], viewport[3]);
|
|
|
|
}
|
|
|
|
|
|
|
|
#undef VIEWPORT_TRANSFORM_X
|
|
|
|
#undef VIEWPORT_TRANSFORM_Y
|
2010-05-26 06:33:32 -04:00
|
|
|
|
2012-08-31 14:28:27 -04:00
|
|
|
uint32_t
|
|
|
|
_cogl_system_error_quark (void)
|
2010-05-26 06:33:32 -04:00
|
|
|
{
|
2012-08-31 14:28:27 -04:00
|
|
|
return g_quark_from_static_string ("cogl-system-error-quark");
|
2010-05-26 06:33:32 -04:00
|
|
|
}
|
2011-06-14 17:33:44 -04:00
|
|
|
|
|
|
|
void
|
|
|
|
_cogl_init (void)
|
|
|
|
{
|
2018-11-24 07:04:47 -05:00
|
|
|
static gboolean initialized = FALSE;
|
2011-06-14 17:33:44 -04:00
|
|
|
|
2012-09-12 18:47:17 -04:00
|
|
|
if (initialized == FALSE)
|
2011-06-14 17:33:44 -04:00
|
|
|
{
|
2016-06-16 16:31:38 -04:00
|
|
|
#if !GLIB_CHECK_VERSION (2, 36, 0)
|
2011-06-14 17:33:44 -04:00
|
|
|
g_type_init ();
|
2012-09-15 09:39:29 -04:00
|
|
|
#endif
|
2011-06-14 17:33:44 -04:00
|
|
|
|
|
|
|
_cogl_debug_check_environment ();
|
2012-09-12 18:47:17 -04:00
|
|
|
initialized = TRUE;
|
2011-06-14 17:33:44 -04:00
|
|
|
}
|
|
|
|
}
|