Previously it would only try to set the blend equation if the RGB and
alpha blending functions were different. However it's completely valid
to use a non-standard blending function when the functions are the
same. This patch moves the blending equation to outside the if
statement.
Previously it would only set the blend constant if glBlendFuncSeparate
was used but it is perfectly acceptable to use the blend constant when
the same factor is used for each. It now sets the blend constant
whenever one of the factors would use the constant.
When a single statement is used to specify the factors for both the
RGB and alpha parts it previously split up the statement into
two. This works but it ends up unnecessarily using glBlendFuncSeparate
when glBlendFunc would suffice.
For example, the blend statement
RGBA = ADD(SRC_COLOR*(SRC_COLOR), DST_COLOR*(1-SRC_COLOR))
would get split into the two statements
RGBA = ADD(SRC_COLOR*(SRC_COLOR[RGB]), DST_COLOR*(1-SRC_COLOR[RGB]))
A = ADD(SRC_COLOR*(SRC_COLOR[A]), DST_COLOR*(1-SRC_COLOR[A]))
That translates to:
glBlendFuncSeparate (GL_SRC_COLOR, GL_ONE_MINUS_SRC_COLOR,
GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
This patch makes it so that arg_to_gl_blend_factor can handle the
combined RGBA mask instead. That way the single statement gets
translated to the equivalent call:
glBlendFunc (GL_SRC_COLOR, GL_ONE_MINUS_SRC_COLOR);
Previously a path copy was implemented such that only the array of
path nodes was shared with the source and the rest of the data is
copied. This was so that the copy could avoid a deep copy if the
source path is appended to because the copy keeps track of its own
length. This optimisation is probably not worthwhile because it makes
the copies less cheap. Instead the CoglPath struct now just contains a
single pointer to a new CoglPathData struct which is separately
ref-counted. When the path is modified it will be copied if the ref
count on the data is not 1.
Since framebuffer state is not flushed prior to replaying the journal,
the trick of marking the framebuffer dirty prior to calling
glBindFramebuffer() doesn't work... the outstanding journal entries
will get replayed to the newly created framebuffer.
Fix this by flushing the journal as well.
http://bugzilla.openedhand.com/show_bug.cgi?id=2110
Signed-off-by: Robert Bragg <robert@linux.intel.com>
If the clip stack is empty then _cogl_clip_stack_flush exits
immediately. This was missing out the assignment of *stencil_used_p at
the bottom of the function. If a path is then used after the clip is
cleared then it would think it needs to merge with the clip so the
stencil would not be cleared correctly.
In 91cde78a7 I accidentally changed the function names that get looked
up for the framebuffer extension under GLES so that they didn't have
any suffix. The spec for extension specifies that they should have the
OES suffix.
Debugging code is not meant to be run in the nominal code path. Use
G_UNLIKELY to be reduce the number of bubbles in the instruction
pipeline.
Took the opportunity to re-indent the macros.
When uploading texture data the cogl-texture-2d-sliced backend was
using _cogl_texture_prepare_for_upload to create a bitmap suitable for
upload but then it was using the original bitmap instead of the new
bitmap for the data. This was causing any format conversions performed
by cogl_texture_prepare_for_upload to be ignored.
http://bugzilla.openedhand.com/show_bug.cgi?id=2059
In commit abe91784c4 I changed cogl-texture so that it would use the
OpenGL mechanism to specify a different internal texture format from
the image format so that it can do the conversion instead of
Cogl. However under GLES the internal format and the image format must
always be the same and it only supports a limited set of formats. This
patch changes _cogl_texture_prepare_for_upload so that it does the
conversion using the cogl bitmap code when compiling for GLES.
http://bugzilla.openedhand.com/show_bug.cgi?id=2059
There was a check at the bottom of the loop which sets up the state
for each of the layers so that it would break from the loop when the
maximum number of layers is reached. However after doing this it would
not increment 'i'. 'i' is later used to disable the remaining layers
so it would end up disabling the last layer it just set up.
This patch moves the check to be part of the loop condition so that
the check is performed after incrementing 'i'.
http://bugzilla.openedhand.com/show_bug.cgi?id=2064
The warning displayed when too many layers are used had an off-by-one
error so that it would display even if exactly the maximum number is
used. There was also a missing space at the end of the line in the
message which looked wrong when displayed on the terminal.
http://bugzilla.openedhand.com/show_bug.cgi?id=2064
cogl_path_arc_rel was never in any public headers so it isn't part of
the public API. It also has a slightly inconsistent name because the
rest of the relative path functions are called cogl_path_rel_*. This
patch makes it static for now to make it more obvious that it isn't
public. The name has changed to _cogl_path_rel_arc.
If a path is copied and then appended to, the copy needs to have the
last sub path truncated so that it fits in the total path size in case
the original path was modified. However the path size check was broken
so if the copied path had more than one sub path it would fail.
Previously the clip stack code was trying to detect when the
orientation of the on-screen rectangle had changed by checking if the
order of the y-coordinates on the left edge was different from the
order the x-coordinates on the top edge. This doesn't work for some
rotations which was causing the clip planes to clip the wrong side of
the line. This patch makes it detect the orientation by calculating
the signed area which is a standard computer graphics algorithm.
http://bugzilla.openedhand.com/show_bug.cgi?id=2079
When drawing a path with only a single sub path, Cogl uses the
'even-odd' fill rule which means that if a part of the path intersects
with another part then the intersection would be inverted. However
when combining sub paths it treats them as separate paths and then
unions them together. This doesn't match the semantics of the even-odd
rule in SVG and Cairo. This patch makes it so that a new sub path is
just drawn as another triangle fan so that it will continue to invert
the stencil buffer. This is also much simpler and more efficient as
well as being more correct.
http://bugzilla.openedhand.com/show_bug.cgi?id=2088
Under GLES glReadPixels is documented to only support GL_RGBA with
GL_UNSIGNED_BYTE and an implementation specfic format which can be
fetched with glGet, GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES and
GL_IMPLEMENTATION_COLOR_READ_TYPE_OES. This patch makes it always read
using GL_RGBA and GL_UNSIGNED_BYTE and then convert the results if
neccessary.
This has some room for improvement because it doesn't attempt to use
the implementation specific format. Also the conversion is somewhat
wasteful because there are currently no cogl_bitmap_* functions to
convert without allocating a new buffer so it ends up doing an
intermediate copy.
http://bugzilla.openedhand.com/show_bug.cgi?id=2057
_cogl_bitmap_convert_format_and_premult was failing when converting
from RGBA to RGB and vice versa. _cogl_bitmap_fallback_convert
converts without altering the premult status so when choosing a new
format it would copy over the premult bit. However, it did this
regardless of whether the new format had an alpha channel so when
converting from RGBA_8888_PRE to RGB_888 it would end up inventing a
new meaningless format which would be RGB_888_PRE. This patch makes it
avoid copying the premult flag if the destination has no alpha. It
doesn't matter if it copies when the source format has no alpha
because it will always be unset.
_cogl_bitmap_convert_format_and_premult was also breaking when
converting from RGBA_8888_PRE to RGB_888 because it would think
RGB_888 is unpremultiplied and try to convert but then
_cogl_bitmap_fallback_premult wouldn't know how to do the conversion.
http://bugzilla.openedhand.com/show_bug.cgi?id=2057
This adds three new internal API functions which can be used to retain
the clip stack state and restore it later:
_cogl_get_clip_stack
_cogl_set_clip_stack
_cogl_clip_stack_copy
The functions are currently internal and not yet used but we may want
to make them public in future to replace the cogl_clip_stack_save()
and cogl_clip_stack_restore() APIs.
The get function just returns the handle to the clip stack at the top
of the stack of stacks and the set function just replaces it.
The copy function makes a cheap copy of an existing stack by taking a
reference to the top stack entry. This ends up working like a deep
copy because there is no way to modify entries of a stack but it
doesn't actually copy the data.
CoglClipStackState has now been renamed to CoglClipState and is moved
to a separate file. CoglClipStack now just maintains a stack and
doesn't worry about the rest of the state. CoglClipStack sill contains
the code to flush the stack to GL.
When glScissor is called it needs to pass coordinates in GL's
coordinate space where the origin is the bottom left. Previously this
conversion was done before storing the window rect in the clip
stack. However this might make it more difficult if we want to be able
to grab a handle to a clip stack and use it in different circumstances
later. This patch moves the coordinate conversion to inside the clip
state flushing code.
The stack is now stored as a list of reference counted entries.
Instead of using a GList, each entry now contains a link with a
reference to its parent. The idea is that this would allow copying
stacks with a shared ancestry.
Previously the code flushed the state by finding the bottom of the
stack and then applying each entry by walking back up to the top. This
is slightly harder to do now because the list is no longer
doubly-linked. However I don't think it matters which order the
entries are applied so I've just changed it to apply them in reverse
order.
There was also a restriction that if ever the stencil buffer is used
then we could no longer use clip planes for any subsequent entries. I
don't think this makes sense because it should always work as long as
it doesn't attempt to use the clip planes more than once. I've
therefore removed the restriction.
The CoglAtlasTexture struct was not being freed in
_cogl_atlas_texture_free so there would be a small leak whenever a
texture was destroyed.
Thanks to Robert Bragg for spotting this.
CoglMaterial now sets GL_CLAMP_TO_EDGE if WRAP_MODE_AUTOMATIC is used
unless it is overridden when the material is flushed. The primitives
are still expected to expose repeat semantics so no user visible
changes are made. The idea is that drawing non-repeated textures is
the most common case so if we make clamp_to_ege the default then we
will reduce the number of times we have to override the
material. Avoiding overrides will become important if the overriding
mechanism is replaced with one where the primitive is expected to copy
the material and change that instead.
Previously, Cogl's texture coordinate system was effectively always
GL_REPEAT so that if an application specifies coordinates outside the
range 0→1 it would get repeated copies of the texture. It would
however change the mode to GL_CLAMP_TO_EDGE if all of the coordinates
are in the range 0→1 so that in the common case that the whole texture
is being drawn with linear filtering it will not blend in edge pixels
from the opposite sides.
This patch adds the option for applications to change the wrap mode
per layer. There are now three wrap modes: 'repeat', 'clamp-to-edge'
and 'automatic'. The automatic map mode is the default and it
implements the previous behaviour. The wrap mode can be changed for
the s and t coordinates independently. I've tried to make the
internals support setting the r coordinate but as we don't support 3D
textures yet I haven't exposed any public API for it.
The texture backends still have a set_wrap_mode virtual but this value
is intended to be transitory and it will be changed whenever the
material is flushed (although the backends are expected to cache it so
that it won't use too many GL calls). In my understanding this value
was always meant to be transitory and all primitives were meant to set
the value before drawing. However there were comments suggesting that
this is not the expected behaviour. In particular the vertex buffer
drawing code never set a wrap mode so it would end up with whatever
the texture was previously used for. These issues are now fixed
because the material will always set the wrap modes.
There is code to manually implement clamp-to-edge for textures that
can't be hardware repeated. However this doesn't fully work because it
relies on being able to draw the stretched parts using quads with the
same values for tx1 and tx2. The texture iteration code doesn't
support this so it breaks. This is a separate bug and it isn't
trivially solved.
When flushing a material there are now extra options to set wrap mode
overrides. The overrides are an array of values for each layer that
specifies an override for the s, t or r coordinates. The primitives
use this to implement the automatic wrap mode. cogl_polygon also uses
it to set GL_CLAMP_TO_BORDER mode for its trick to render sliced
textures. Although this code has been added it looks like the sliced
trick has been broken for a while and I haven't attempted to fix it
here.
I've added a constant to represent the maximum number of layers that a
material supports so that I can size the overrides array. I've set it
to 32 because as far as I can tell we have that limit imposed anyway
because the other flush options use a guint32 to store a flag about
each layer. The overrides array ends up adding 32 bytes to each flush
options struct which may be a concern.
http://bugzilla.openedhand.com/show_bug.cgi?id=2063
GL supports setting different wrap modes for the s, t and r
coordinates so we should design the backend interface to support that
also. The r coordinate is not currently used by any of the backends
but we might as well have it to make life easier if we ever add
support for 3D textures.
http://bugzilla.openedhand.com/show_bug.cgi?id=2063
CoglColor and CoglMatrix have public declarations with private members
so that we are free to change the implementation but the structures
could still be allocated on the stack in applications. However it's
quite easy not to realise the members are private and then access them
directly. This patch wraps the members in a macro which redefines the
symbol name when including the header outside of the clutter source.
http://bugzilla.openedhand.com/show_bug.cgi?id=2065
The xx, yx, zx etc fields are meant to be read-only but they were
marked as private with the gtk-doc annotation. This patch moves the
private marker so that the 16 float member fields are public but the
type, inverted matrix, flags and padding are not.
This adds three new API calls:
CoglHandle cogl_path_get()
void cogl_path_set(CoglHandle path)
CoglHandle cogl_path_copy(CoglHandle path)
All of the fields relating to the path have been moved from the Cogl
context to a new CoglPath handle type. The cogl context now just
contains a CoglPath handle. All of the existing path commands
manipulate the data in the current path handle. cogl_path_new now just
creates a new path handle and unrefs the old one.
The path handle can be stored for later with cogl_path_get. The path
can then be copied with cogl_path_copy. Internally it implements
copy-on-write semantics with an extra optimisation that it will only
copy the data if the new path is modified, but not if the original
path is modified. It can do this because the only way to modify a path
is by appending to it so the copied path is able to store its own path
length and only render the nodes up to that length. For this to work
the copied path also needs to keep its own copies of the path extents
because the parent path may change these by adding nodes.
The clip stack now uses the cogl_path_copy mechanism to store paths in
the stack instead of directly copying the data. This should save some
memory and processing time.
Although cogl_multiply_matrix was consistent with OpenGL, after further
consideration it was agreed that cogl_transform is a better name. Given
that it's in the global cogl_ namespace cogl_transform seems more self
documenting.
This adds an example of how to setup a Clutter style 2D coordinate space
and clarifies what state is owned by a framebuffer. (projection,
modelview, viewport and clip stack)
When we expose more cogl_framebuffer API this example will hopefully be
migrated into a more extensive introduction to using framebuffers.
Previously cogl_set_source and cogl_set_source_texture were in
cogl-material.c and the cogl_set_source_color* funcs were in
cogl-color.c. Originally this was because cogl.c was duplicated between
the GL and GLES backends and we didn't want to add to the amount of
duplicated code, but these files have since been consolidated into one
cogl.c.
Quite often it's desirable to be able to multiply the current modelview
matrix by an arbitrary matrix. Currently though you have to first
explicitly call cogl_get_modelview_matrix to get the current modelview
into a temporary variable, then you need to multiply it with your matrix
using cogl_matrix_multiply and finally use cogl_set_modelview_matrix to
make the result be the new modelview. This new convenience function lets
more efficiently skip the first get and last set steps.
Every now and then someone sees the cogl_enable API and gets confused,
thinking its public API so this renames the symbol to be clear that it's
is an internal only API.
When setting up the state for a layer, we need to switch texture
units before we do anything that might bind the texture, or
we'll bind the wrong texture to the previous unit.
http://bugzilla.openedhand.com/show_bug.cgi?id=2033
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
We need to set up the rowstride and alignment properly in
CoglTexture2D before reading texture data.
http://bugzilla.openedhand.com/show_bug.cgi?id=2036
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
This makes it more likely consumers notice invalid unreferences.
GObject has the same assertion.
http://bugzilla.openedhand.com/show_bug.cgi?id=2029
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
When entering cogl_texture_2d_new_from_bitmap the internal format can
be COGL_PIXEL_FORMAT_ANY. This was causing _cogl_texture_2d_can_create
to use an invalid GL format type. Mesa apparently ignores this but it
was causing errors when Cogl is compiled with debugging under NVidia.
http://bugzilla.openedhand.com/show_bug.cgi?id=2026
Add a return result from CoglTexture.transform_quad_coords_to_gl(),
so that we can properly determine the nature of repeats in
the face of GL_TEXTURE_RECTANGLE_ARB, where the returned
coordinates are not normalized.
The comment "We also work out whether any of the texture
coordinates are outside the range [0.0,1.0]. We need to do
this after calling transform_coords_to_gl in case the texture
backend is munging the coordinates (such as in the sub texture
backend)." is disregarded and removed, since it's actually
the virtual coordinates that determine whether we repeat,
not the GL coordinates.
Warnings about disregarded layers are used in all cases where
applicable, including for subtextures.
http://bugzilla.openedhand.com/show_bug.cgi?id=2016
Signed-off-by: Neil Roberts <neil@linux.intel.com>
In _cogl_texture_2d_sliced_foreach_sub_texture_in_region(), don't
assert that the target is GL_TEXTURE_2D; instead conditionalize
normalization on the target.
http://bugzilla.openedhand.com/show_bug.cgi?id=2015
