mutter/fixed-to-float-patches/cogl-primitives.c.0.patch

diff --git a/clutter/cogl/common/cogl-primitives.c b/clutter/cogl/common/cogl-primitives.c
index 7dfc78e..c9578db 100644
--- a/clutter/cogl/common/cogl-primitives.c
+++ b/clutter/cogl/common/cogl-primitives.c
@@ -33,6 +33,7 @@
 
 #include <string.h>
 #include <gmodule.h>
+#include <math.h>
 
 #define _COGL_MAX_BEZ_RECURSE_DEPTH 16
First cut at a fixed point to floating point conversion script + patches This commit doesn't actually include any direct changes to source; you have to run ./fixed-to-float.sh. Note: the script will make a number of commits itself to your git repository a various stages of the script. You will need to reset these if you want to re-run the script. * NB: Be carefull about how you reset your tree, if you are making changes to the script and patches, so you don't loose your changes * This aims to remove all use of fixed point within Clutter and Cogl. It aims to not break the Clutter API, including maintaining the CLUTTER_FIXED macros, (though they now handle floats not 16.16 fixed) It maintains cogl-fixed.[ch] as a utility API that can be used by applications (and potentially for focused internal optimisations), but all Cogl interfaces now accept floats in place of CoglFixed. Note: the choice to to use single precision floats, not doubles is very intentional. GPUs are basically all single precision; only this year have high end cards started adding double precision - aimed mostly at the GPGPU market. This means if you pass doubles into any GL[ES] driver, you can expect those numbers to be cast to a float. (Certainly this is true of Mesa wich casts most things to floats internally) It can be a noteable performance issue to cast from double->float frequently, and if we were to have an api defined in terms of doubles, that would imply a lot of unneeded casting. One of the noteable issues with fixed point was the amount of casting required, so I don't want to overshoot the mark and require just as much casting still. Double precision arithmatic is also slower, so it usually makes sense to minimize its use if the extra precision isn't needed. In the same way that the fast/low precision fixed API can be used sparingly for optimisations; if needs be in certain situations we can promote to doubles internally for higher precision. E.g. quoting Brian Paul (talking about performance optimisations for GL programmers): "Avoid double precision valued functions Mesa does all internal floating point computations in single precision floating point. API functions which take double precision floating point values must convert them to single precision. This can be expensive in the case of glVertex, glNormal, etc. " 2008-12-19 16:55:35 -05:00			`diff --git a/clutter/cogl/common/cogl-primitives.c b/clutter/cogl/common/cogl-primitives.c`
			`index 7dfc78e..c9578db 100644`
			`--- a/clutter/cogl/common/cogl-primitives.c`
			`+++ b/clutter/cogl/common/cogl-primitives.c`
			`@@ -33,6 +33,7 @@`

			`#include <string.h>`
			`#include <gmodule.h>`
			`+#include <math.h>`

			`#define _COGL_MAX_BEZ_RECURSE_DEPTH 16`