For example cogl_wrap_glFrustumx -> cogl_wrap_glFrustumf.
The wrappers get #defined to the float versions anyway but it helps
avoid some confusion.
The conversion is done using a regular expression in the upgrade
script. Some of the patches had to be updated to apply cleanly.
It looks like the changes to cogl-gles2-wrapper.h were accidentally
committed to the actual file instead of the patch in commit
de27da0e. This commit moves the changes back into the patch so
cogl-gles2-wrapper.h is reverted back to master.
The wrapper for glClearColor was taking fixed arguments but was given
floating point values so it ended up always setting the clear color to
black. Now that GLES 1.1 is using the floating point version, there is
no need for the wrapper so both versions now just use glClearColor
directly.
A similar problem was happening for glColor but this does still need a
wrapper because it needs to set the vertex attribute.
The patches have been updated to apply cleanly.
The patches for the g_warnings in clutter-actor.c have been removed
because master now uses CLUTTER_UNITS_FORMAT so they aren't
necessary. The clutter-units.h patch now sets CLUTTER_UNITS_FORMAT to
'f'.
The GL versions of get_modelview_matrix, get_projection_matrix and
get_viewport were using glGetDoublev and then converting them to
floats, but it might as well just call glGetFloatv directly.
The GL ES versions were using glGetFixedv but this was being replaced
with glGetFloatv by the #define in the GLES 2 wrappers.
The patch also replaces the glGetFixedv wrapper with
glGetFloatv. Previously this was calling
cogl_gles2_float_array_to_fixed which actually converted to
float. That function has been removed and memcpy is used instead.
Since they are no longer actually taking fixed point parameters the 'x' suffix is
no longer appropriate. To maintain support for sub-pixel precision the
corresponding interfaces that were taking integer parameters now get patched
to take float parameters instead.
These functions are defined to take an angle in degrees, so the angle needs
converting before calling the corresponding {sin,cos,tan,atan}f()
This fixes test-cogl-tex-tile.
Most of the patches updated weren't failing but there were a number of
hunk offsets when applying so it tidies that up. The change in
mtx_transform.0.patch has been moved to clutter-actor.c.0.patch.
The previous patch broke some of the normalization done before the sine value
gets multiplied with CLUTTER_ALPHA_MAX. This e.g. broke test-actors when sine
values went through to -1, as the o-hands were scaled so large all you saw was
the red 'O'.
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. "
