We were checking the number of texture units against the GL enum that is
used in glGetInteger() to query that number. Let's abstract this in a
little function.
Took the opportunity to dig a bit on the usage of GL limits for the
number of texture (image) units and document our use of them. We'll need
something finer grained if we want to fully exploit texture image units
with a programmable pipeline.
We were checking the number of texture units against the GL enum that is
used in glGetInteger() to query that number. Let's abstract this in a
little function.
Took the opportunity to dig a bit on the usage of GL limits for the
number of texture (image) units and document our use of them. We'll need
something finer grained if we want to fully exploit texture image units
with a programmable pipeline.
An example of what could be the equivalent of
"RBG = REPLACE(TEXTURE)
A = MODULATE(PREVIOUS,TEXTURE)"
using the ARB_texture_env_combine extension was given, but it seems that
a few typo were left:
* remove a spurius GL_COMBINE_ALPHA
* use the _ALPHA variant of SRCN and OPERANDN when setting up the
alpha combiner
An example of what could be the equivalent of
"RBG = REPLACE(TEXTURE)
A = MODULATE(PREVIOUS,TEXTURE)"
using the ARB_texture_env_combine extension was given, but it seems that
a few typo were left:
* remove a spurius GL_COMBINE_ALPHA
* use the _ALPHA variant of SRCN and OPERANDN when setting up the
alpha combiner
It's very useful to see the actual number the reference value is
compared too when the test fails. GTest has g_assert_cmp$type()
functions for that, so make good use of them.
A small doubt has risen about the use of CoglTextureUnit in materials:
will texture matrices still work if we have several materials, each of
them having at texture on the same texture unit? The answer is yes!
test-cogl-multitexture has been extended to use 2 materials with about
the same setup except a little difference: the texture matrices for the
lightmaps rotate in opposite directions.
While at it, changed the rotation behaviour by an implicit animation
with a small additional bonus bling.
The index field of CoglTextureUnit was never set, leading to the
creation of units with index set to 0. When trying to retrieve a texture
unit by its index (!= 0) with _cogl_get_texture_unit(), a new one was
created as it could not find it back in the list of textures units:
ctx->texture_units.
http://bugzilla.openedhand.com/show_bug.cgi?id=1958
The index field of CoglTextureUnit was never set, leading to the
creation of units with index set to 0. When trying to retrieve a texture
unit by its index (!= 0) with _cogl_get_texture_unit(), a new one was
created as it could not find it back in the list of textures units:
ctx->texture_units.
http://bugzilla.openedhand.com/show_bug.cgi?id=1958
When putting 32-bit properties into longs on 64-bit architectures,
XGetWindowProperty assumes the values are supposed to be signed, and
so it sign-extends values greater than 0x7fffffff. So if they *aren't*
supposed to be signed, we need to chop off the high bits ourselves.
(Most CARDINAL-valued properties only end up using small values
anyway, so it doesn't matter, but _NET_WM_WINDOW_OPACITY uses the full
range, and so was previously failing on 64-bit machines.)
https://bugzilla.gnome.org/show_bug.cgi?id=605678
The :opacity property is defined using a GParamSpecUchar. This usually
leads to issues with language bindings that don't have an 'unsigned
char' type and that need to explicitly handle the conversion between
G_TYPE_UCHAR and G_TYPE_INT or G_TYPE_UINT.
The property definition already specifies an interval size of [0, 255]
on the values; more importantly, GObject already implicitly transforms
between G_TYPE_UCHAR and G_TYPE_UINT (the GValue transformation
functions are registered at type system initialization time) so
switching between a GParamSpecUchar and a GParamSpecUint should not be
an ABI break.
I have tested a simple program using the opacity property before and
after the change and I cannot see any run-time warnings related to this
issue.
Be more drastic if the internal state is broken, and assert() if the
expected Alpha and Timeline instances we need are not valid. This
usually implies a library bug or a massive heap corruption.
The Animation code does transformation of values between type A and A'
after checking for compatibility using g_value_type_compatible(). This
is incorrect: compatibility means that the two types can be copied. The
correct conversion should follow:
if (compatible (type (A), type (A')))
copy (A, A');
else
if (transformable (type (A), type (A')))
transform (A, A');
else
error("Unable to trasform type A in A'");
The transformation might still fail, so we need to check for errors
there as well as a fall-through case.
We should not just check for compatibility, but also for the ability to
transform a GValue of type A into another of type A'.
Usually compatibility is enough, especially if types can be
introspected beforehand; some times, though, we also need to check for
transformability as a type can provide the transformation functions
necessary for the operation.
The MetaDirection enumeration had META_SIDE_* values in it that
were used in some places where an enum with only four directions
was needed. Split this off into a separate enum called MetaSide
and use that enum name where appropriate.
The commit 1c69c61745ed510f0b6ab16cb963ca01994cb9fc which improved the
protection against timeline removals during the master clock advancement
was only doing half the job - and actually broke the chaining of
animations inside the ::completed signal.
We cannot simply take a reference on the timelines and still use the list
held by the master clock because the do_tick() might result in the
creation of a new timeline, which gets added at the end of the list with
no reference increase and thus gets disposed at the end of the iteration.
We also cannot steal the master clock timelines list because a timeline
might be removed as the direct result of do_tick() and remove_timeline()
would not find the timeline, failing and leaving a dangling pointer
behind.
For this reason we copy the list of timelines out of the one that the
Master Clock holds, take a reference on each timeline, advance them all,
release the reference and free the list.
The extension keyboard support in XInput 1.x is hopelessly broken.
Nevertheless, it's possible to use some bits of it, as we prefer the
core keyboard events to the XInput events, thus at least having proper
handling for X11 key events on the Stage window.
The XI 1.0 layer is complementary to the X11 core devices handling; this
means that core events will still be emitted for the core pointer and
keyboard devices, and that secondary (floating) devices should be
handled on top of that.
Thus, the XI event handling code should be executed (if explicitly
compiled in and enabled) if the core device events have not been parsed.
Note: this is going away with XI2, which completely replaces both core and
XI1 events.
Even with XInput support we should always register core devices. This
allows us to handle enter and leave events correctly on the Stage and
to have a working XInput 1.x support in Clutter.
Mostly lifted from the core pointer and keyboard X11 backend support.
The win32 backend registers two devices (a core pointer and a core
keyboard) and assigns them to the event structure when doing the
translation from native events to Clutter events.
Thanks to: Samuel Degrande <Samuel.Degrande@lifl.fr> for testing this
patch.
Instead of overloading the device id of 0 and 1 we should treat the core
devices as special, and have a pointer inside the X11 backend singleton
structure, for fast access.
