We don't want to force texture data to be premultipled if the user
explicitly specifies a non premultiplied internal_format such as
COGL_PIXEL_FORMAT_RGBA_8888. So now Cogl will only automatically
premultiply data when COGL_PIXEL_FORMAT_ANY is given for the
internal_format, or a premultiplied internal format such as
COGL_PIXEL_FORMAT_RGBA_8888_PRE is requested but non-premultiplied source
data is given.
This approach is consistent with OpenVG image formats which have already
influenced Cogl's pixel format semantics.
Many operations, like mixing two textures together or alpha-blending
onto a destination with alpha, are done most logically if texture data
is in premultiplied form. We also have many sources of premultiplied
texture data, like X pixmaps, FBOs, cairo surfaces. Rather than trying
to work with two different types of texture data, simplify things by
always premultiplying texture data before uploading to GL.
Because the default blend function is changed to accommodate this,
uses of pure-color CoglMaterial need to be adapted to add
premultiplication.
gl/cogl-texture.c gles/cogl-texture.c: Always premultiply
non-premultiplied texture data before uploading to GL.
cogl-material.c cogl-material.h: Switch the default blend functions
to ONE, ONE_MINUS_SRC_ALPHA so they work correctly with premultiplied
data.
cogl.c: Make cogl_set_source_color() premultiply the color.
cogl.h.in color-material.h: Add some documentation about
premultiplication and its interaction with color values.
cogl-pango-render.c clutter-texture.c tests/interactive/test-cogl-offscreen.c:
Use premultiplied colors.
http://bugzilla.openedhand.com/show_bug.cgi?id=1406
Signed-off-by: Robert Bragg <robert@linux.intel.com>
Otherwise if there is an error before the slices are created it will
try to free the first_pixels array and crash.
It now also checks whether first_pixels has been created before using
it to update the mipmaps. This should only happen for
cogl_texture_new_from_foreign and doesn't matter if the FBO extension
is available. It would be better in this case to fetch the first pixel
using glGetTexImage as Owen mentioned in the last commit.
tex->first_pixels was never set for foreign textures, leading
to a crash when the texture object is freed.
As a quick fix, simply set to NULL. A more complete fix would
require remembering if we had ever seen the first pixel uploaded,
and if not, doing a glReadPixel to get it before triggering the
mipmap update.
http://bugzilla.openedhand.com/show_bug.cgi?id=1645
Signed-off-by: Neil Roberts <neil@linux.intel.com>
* 1.0-integration: (138 commits)
[x11] Disable XInput by default
[xinput] Invert the XI extension version check
[cogl-primitives] Fix an unused variable warning when building GLES
[clutter-stage-egl] Pass -1,-1 to clutter_stage_x11_fix_window_size
Update the GLES backend to have the layer filters in the material
[gles/cogl-shader] Add a missing semicolon
[cogl] Move the texture filters to be a property of the material layer
[text] Fix Pango unit to pixels conversion
[actor] Force unrealization on destroy only for non-toplevels
[x11] Rework map/unmap and resizing
[xinput] Check for the XInput entry points
[units] Validate units against the ParamSpec
[actor] Add the ::allocation-changed signal
[actor] Use flags to control allocations
[units] Rework Units into logical distance value
Remove a stray g_value_get_int()
Remove usage of Units and macros
[cogl-material] Allow setting a layer with an invalid texture handle
[timeline] Remove the concept of frames from timelines
[gles/cogl-shader] Fix parameter spec for cogl_shader_get_info_log
...
Conflicts:
configure.ac
The texture filters are now a property of the material layer rather
than the texture object. Whenever a texture is painted with a material
it sets the filters on all of the GL textures in the Cogl texture. The
filter is cached so that it won't be changed unnecessarily.
The automatic mipmap generation has changed so that the mipmaps are
only generated when the texture is painted instead of every time the
data changes. Changing the texture sets a flag to mark that the
mipmaps are dirty. This works better if the FBO extension is available
because we can use glGenerateMipmap. If the extension is not available
it will temporarily enable automatic mipmap generation and reupload
the first pixel of each slice. This requires tracking the data for the
first pixel.
The COGL_TEXTURE_AUTO_MIPMAP flag has been replaced with
COGL_TEXTURE_NO_AUTO_MIPMAP so that it will default to
auto-mipmapping. The mipmap generation is now effectively free if you
are not using a mipmap filter mode so you would only want to disable
it if you had some special reason to generate your own mipmaps.
ClutterTexture no longer has to store its own copy of the filter
mode. Instead it stores it in the material and the property is
directly set and read from that. This fixes problems with the filters
getting out of sync when a cogl handle is set on the texture
directly. It also avoids the mess of having to rerealize the texture
if the filter quality changes to HIGH because Cogl will take of
generating the mipmaps if needed.
When creating a Cogl texture from a Cogl bitmap it would steal the
data by setting the bitmap_owner flag and clearing the data pointer
from the bitmap. The data would be freed by the time the
new_from_bitmap is finished. There is no reason to do this because the
data will be freed when the Cogl bitmap is unref'd and it is confusing
not to be able to reuse the bitmap for creating multiple textures.
The CoglTexture constructors expose the "max-waste" argument for
controlling the maximum amount of wasted areas for slicing or,
if set to -1, disables slicing.
Slicing is really relevant only for large images that are never
repeated, so it's a useful feature only in controlled use cases.
Specifying the amount of wasted area is, on the other hand, just
a way to mess up this feature; 99% the times, you either pull this
number out of thin air, hoping it's right, or you try to do the
right thing and you choose the wrong number anyway.
Instead, we can use the CoglTextureFlags to control whether the
texture should not be sliced (useful for Clutter-GST and for the
texture-from-pixmap actors) and provide a reasonable value for
enabling the slicing ourself. At some point, we might even
provide a way to change the default at compile time or at run time,
for particular platforms.
Since max_waste is gone, the :tile-waste property of ClutterTexture
becomes read-only, and it proxies the cogl_texture_get_max_waste()
function.
Inside Clutter, the only cases where the max_waste argument was
not set to -1 are in the Pango glyph cache (which is a POT texture
anyway) and inside the test cases where we want to force slicing;
for the latter we can create larger textures that will be bigger than
the threshold we set.
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Signed-off-by: Robert Bragg <robert@linux.intel.com>
Signed-off-by: Neil Roberts <neil@linux.intel.com>
COGL has a debug message system like Clutter's own. In parallel,
it also uses a coupld of #defines. Spread around there are also
calls to printf() instead to the more correct g_log* wrappers.
This commit tries to unify and clean up the macros and the
debug message handling inside COGL to be more consistent.
COGLenum, COGLint and COGLuint which were simply typedefs for GL{enum,int,uint}
have been removed from the API and replaced with specialised enum typedefs, int
and unsigned int. These were causing problems for generating bindings and also
considered poor style.
The cogl texture filter defines CGL_NEAREST and CGL_LINEAR etc are now replaced
by a namespaced typedef 'CoglTextureFilter' so they should be replaced with
COGL_TEXTURE_FILTER_NEAREST and COGL_TEXTURE_FILTER_LINEAR etc.
The shader type defines CGL_VERTEX_SHADER and CGL_FRAGMENT_SHADER are handled by
a CoglShaderType typedef and should be replaced with COGL_SHADER_TYPE_VERTEX and
COGL_SHADER_TYPE_FRAGMENT.
cogl_shader_get_parameteriv has been replaced by cogl_shader_get_type and
cogl_shader_is_compiled. More getters can be added later if desired.
Adds missing notices, and ensures all the notices are consistent. The Cogl
blurb also now reads:
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
The cogl_is_* functions were showing up quite high on profiles due to
iterating through arrays of cogl handles.
This does away with all the handle arrays and implements a simple struct
inheritance scheme. All cogl objects now add a CoglHandleObject _parent;
member to their main structures. The base object includes 2 members a.t.m; a
ref_count, and a klass pointer. The klass in turn gives you a type and
virtual function for freeing objects of that type.
Each handle type has a _cogl_##handle_type##_get_type () function
automatically defined which returns a GQuark of the handle type, so now
implementing the cogl_is_* funcs is just a case of comparing with
obj->klass->type.
Another outcome of the re-work is that cogl_handle_{ref,unref} are also much
more efficient, and no longer need extending for each handle type added to
cogl. The cogl_##handle_type##_{ref,unref} functions are now deprecated and
are no longer used internally to Clutter or Cogl. Potentially we can remove
them completely before 1.0.
None of this code directly related to implementing CoglTextures, and the
code was needlessly duplicated between the GL and GLES backends. This moves
the cogl_rectangle* and cogl_polygon* code into common/cogl-primitives.c
makes which makes lot of sense since the two copies keep needlessly
diverging introducing or fixing bugs in one but not the other. For instance
I came accross one such bug regarding the enabling of texture units when
unifying the code.
It's often nice to be able to draw a batch of vertices, even if these
have no texture coordinates. This add a cogl_rectangles, similar to
cogl_rectangles_with_texture_coords, only without.
There are various constraints for when we can support multi-texturing and
when they can't be met we try and print a clear warning explaining why the
operation isn't supported, but we shouldn't endlessly repeat the warning for
every primitive of every frame. This patch fixes that.
This is useful because sometimes we need to get the current matrix, which
is too expensive when indirect rendering.
In addition, this virtualization makes it easier to clean up the API in
the future.
All GL functions that are defined in a version later than 1.1 need to
be called through cogl_get_proc_address because the Windows GL DLL
does not export them to directly link against.
When the quad log contains multiple textures (such as when a sliced
texture is drawn) it dispatches the log with multiple calls to
flush_quad_batch and walks a pointer along the list of vertices.
However this pointer was being incremented by only one vertex so the
next quad would be drawn with three of the vertices from the last
quad.
This tries to make a number of files more comparable with the intention of
moving some code into cogl/common/
Files normalized:
cogl.c
cogl-context.c
cogl-context.h
cogl-texture.c
The code is #if 0 guarded, but when uncommented it outlines all drawn
rectangles with an un-blended red, green or blue border. This may e.g. help
with debugging texture slicing issues or blending issues, plus it looks quite
cool.
When drawing a texture with waste in _cogl_multitexture_unsliced_quad
it scales the texture coordinates so that the waste is not
included. However the formula was the wrong way around so it was
calculating as if the texture coordinates are ordered x1,x2,y1,y2 but
it is actually x1,y1,x2,y2.
When the texture is sliced it drops back to a fallback function and
passes it the texture coordinates from the rectangle. However if no
tex coords are given it would crash. Now it passes the default
0.0->1.0 tex coords instead.
If no texture coordinates are given then texture_unsliced_quad tries
to generate its own coordinates. However it also tries to read the
texture coordinates to check if they are in [0.0,1.0] range so it will
crash before it reaches that.
Conflicts:
clutter/cogl/gl/cogl-texture.c
clutter/cogl/gles/cogl-primitives.c
* cogl-material:
clutter-{clone-,}texture weren't updating their material opacity.
Updates GLES1 support for CoglMaterial
Normalizes gl vs gles code in preperation for synching material changes
Removes cogl_blend_func and cogl_alpha_func
Fully integrates CoglMaterial throughout the rest of Cogl
[cogl-material] Restore the GL_TEXTURE_ENV_MODE after material_rectangle
[cogl-material] Make the user_tex_coords parameter of _rectangle const
[test-cogl-material] Remove return value from material_rectangle_paint
Add cogl-material.h and cogl-matrix.h to libclutterinclude_HEADERS
[cogl-material] improvements for cogl_material_rectangle
[cogl-material] Adds a cogl_material_set_color function
[cogl-material] Some improvements for how we sync CoglMaterial state with OpenGL
[cogl-material] Converts clutter-texture/clutter-clone-texture to the material API
[doc] Hooks up cogl-material reference documentation
Updates previous GLES multi-texturing code to use CoglMaterial
Adds a CoglMaterial abstraction, which includes support for multi-texturing
[doc] Hooks up cogl-matrix reference documentation
Adds CoglMatrix utility code
[tests] Adds an interactive unit test for multi-texturing
[multi-texturing] This adds a new cogl_multi_texture API for GL,GLES1 + GLES2
This updates cogl/gles in line with the integration of CoglMaterial throughout
Cogl that has been done for cogl/gl.
Note: This is still buggy, but at least it builds again and test-actors works.
Some GLES2 specific changes were made, but these haven't been tested yet.
This glues CoglMaterial in as the fundamental way that Cogl describes how to
fill in geometry.
It adds cogl_set_source (), which is used to set the material which will be
used by all subsequent drawing functions
It adds cogl_set_source_texture as a convenience for setting up a default
material with a single texture layer, and cogl_set_source_color is now also
a convenience for setting up a material with a solid fill.
"drawing functions" include, cogl_rectangle, cogl_texture_rectangle,
cogl_texture_multiple_rectangles, cogl_texture_polygon (though the
cogl_texture_* funcs have been renamed; see below for details),
cogl_path_fill/stroke and cogl_vertex_buffer_draw*.
cogl_texture_rectangle, cogl_texture_multiple_rectangles and
cogl_texture_polygon no longer take a texture handle; instead the current
source material is referenced. The functions have also been renamed to:
cogl_rectangle_with_texture_coords, cogl_rectangles_with_texture_coords
and cogl_polygon respectivly.
Most code that previously did:
cogl_texture_rectangle (tex_handle, x, y,...);
needs to be changed to now do:
cogl_set_source_texture (tex_handle);
cogl_rectangle_with_texture_coords (x, y,....);
In the less likely case where you were blending your source texture with a color
like:
cogl_set_source_color4ub (r,g,b,a); /* where r,g,b,a isn't just white */
cogl_texture_rectangle (tex_handle, x, y,...);
you will need your own material to do that:
mat = cogl_material_new ();
cogl_material_set_color4ub (r,g,b,a);
cogl_material_set_layer (mat, 0, tex_handle));
cogl_set_source_material (mat);
Code that uses the texture coordinates, 0, 0, 1, 1 don't need to use
cog_rectangle_with_texure_coords since these are the coordinates that
cogl_rectangle will use.
For cogl_texture_polygon; as well as dropping the texture handle, the
n_vertices and vertices arguments were transposed for consistency. So
code previously written as:
cogl_texture_polygon (tex_handle, 3, verts, TRUE);
need to be written as:
cogl_set_source_texture (tex_handle);
cogl_polygon (verts, 3, TRUE);
All of the unit tests have been updated to now use the material API and
test-cogl-material has been renamed to test-cogl-multitexture since any
textured quad is now technically a test of CoglMaterial but this test
specifically creates a material with multiple texture layers.
Note: The GLES backend has not been updated yet; that will be done in a
following commit.
The script converted calls to COGL_FIXED_MUL(x,y) to (x*y). However
this fails for cases like this:
COGL_FIXED_MUL(a + b, c)
which become
(a + b * c)
The meaning of this is of course different because multiplication has
a higher precedence than addition.
This was causing breakages in cogl_texture_quad_sw when the vertex
coordinates are not in increasing order. This was the case in
test-backface-culling when NPOTs are not available.
Boolean arguments for functions are pretty evil and usually
lead to combinatorial explosion of parameters in case multiple
settings are added.
In the case of the COGL texture constructors we have a boolean
argument for enabling the auto-mipmapping; it is conceivable that
we might want to add more settings for a COGL texture without
breaking API or ABI compatibility, so the boolean argument should
become a bitmask.
The internals have not been changed: instead of checking for
a non-zero value, we check for a bitmask being set.
To deal with all the corner cases that couldn't be scripted a number of patches
were written for the remaining 10% of the effort.
Note: again no API changes were made in Clutter, only in Cogl.
This is the result of running a number of sed and perl scripts over the code to
do 90% of the work in converting from 16.16 fixed to single precision floating
point.
Note: A pristine cogl-fixed.c has been maintained as a standalone utility API
so that applications may still take advantage of fixed point if they
desire for certain optimisations where lower precision may be acceptable.
Note: no API changes were made in Clutter, only in Cogl.
Overview of changes:
- Within clutter/* all usage of the COGL_FIXED_ macros have been changed to use
the CLUTTER_FIXED_ macros.
- Within cogl/* all usage of the COGL_FIXED_ macros have been completly stripped
and expanded into code that works with single precision floats instead.
- Uses of cogl_fixed_* have been replaced with single precision math.h
alternatives.
- Uses of COGL_ANGLE_* and cogl_angle_* have been replaced so we use a float for
angles and math.h replacements.
Bug 1289 - Draw multiple glyphs at once
The multiple-texture-rectangle branch adds a new Cogl texture function
called cogl_texture_multiple_rectangles which is used to draw multiple
rectangles out of a texture using a single GL call. This is
significantly faster than drawing the rectangles with individual calls
on some platforms. The Pango renderer now uses this to speed up
rendering.
The conflicts are just due to the whitespace fixes in cb569a5.
Conflicts:
clutter/cogl/gl/cogl-context.c
clutter/cogl/gl/cogl-context.h
clutter/cogl/gl/cogl-texture.c
The rest of Cogl expects the texture mode to be GL_MODULATE so it
needs to be restored after calling cogl_material_rectangle. Otherwise
cogl_texture_rectangle will fail to blend with the Cogl color properly
and all of the labels will be black.
The API has been changed to take an explicit length for the number of
texture coordinates passed, and it's now documented that if there are
more layers to the current material than the number of texture coords
passed, then default coordinates will be generated for the other
layers.
cogl_material_rectangle should now handle the case where a single
sliced texture is supplied as a material layer by falling back to
cogl_texture_rectangle. We are nearly at the point that
cogl_texture_rectangle could be deprecated. A few issues remain
though, such as not considering waste in cogl_material_rectangle.
This flattens the three functions: cogl_material_flush_gl_material_state,
.._flush_gl_alpha_func and .._flush_gl_blend_func into one:
cogl_flush_material_gl_state which doesn't takes a material handle. (the handle
is instead taken from the context.)
This has allows us to avoid re-submitting some state to OpenGL when the
material has not been replaced.
Note: Avoiding redundant state changes for material layers isn't dealt with
in this patch.
Removed trailing white space from the following files:
- clutter-clone-texture.c
- clutter-texture.c
- clutter-texture.h
- cogl/cogl-texture.h
- cogl/gl/cogl-context.c
- cogl/gl/cogl-texture.c
- cogl/gl/cogl-context.h
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
Multitexturing allows blending multiple layers of texture data when texturing
some geometry. A common use is for pre-baked light maps which can give nice
lighting effects relativly cheaply. Another is for dot-3 bump mapping, and
another is applying alpha channel masks.
The dot-3 bump mapping would be really nice one day, but currently cogl doesn't
support lighting so that's not dealt with in this patch.
notable limitations:
- It can only texture rectangles a.t.m - and like cogl_texture_rectangle there
is no support for rotated texturing.
- Sliced textures are not supported. I think I've figured out how to handle
layers with different slice sizes at least for rectangular geometry, but I'm
not sure how complex it becomes once rotations are possible and texturing
arbitrary cogl_polygons.
- Except for this new API, cogl still doesn't know about more than one texture
unit, and so has no way of caching any enables related to other units. So that
things don't break it's currently necessary to disable anything to do with
additional units as soon as we are done with them which isn't ideal.
- No clutter API yet.
There's no point in clearing the index array because it is always the
same sequence of indices regardless of the vertices. Instead it is
just added to when there are more vertices than ever before.
