The internal format of the atlas texture is still set to the
appropriate format so Cogl will disable blending for textures that are
intended to be RGB. This should end up ignoring the alpha channel from
the texture in the atlas. This makes the code slightly easier to
maintain and should also improve the chances of batching.
Since we're allowing allocation cycles saying that calling
queue_relayout() inside an allocation cycle "is not allowed" is kind of
confusing. We should say that "it is not recommended".
* device-manager: (37 commits)
x11: Re-enable XI1 extension keyboards
x11: Always handle core device events before XI events
docs: Documentation fixes for DeviceManager
device-manager: Fix the signals definition
docs: Add sections for InputDevice and DeviceManager
docs: Add clutter_input_device_get_device_name()
tests: Print out the device details on motion
Always register core devices
device: Remove unused is_default member
win32: Experimental implementation of device support
tests: Print the device name, as well as its Id
x11: Fill out the :name property of the InputDevices
device: Add the :name property to InputDevice
x11: Store core devices on the X11 Backend singleton
device: Unset the cursor actor when leaving the stage
device: Add pointer actor getter
x11: Discard the LeaveNotify for off-stage ButtonRelease
device: Do not overwrite the stage for an InputDevice
event: Off-stage button releases have a click count of 1
event: Scroll events do not have click count
...
* device-manager: (37 commits)
x11: Re-enable XI1 extension keyboards
x11: Always handle core device events before XI events
docs: Documentation fixes for DeviceManager
device-manager: Fix the signals definition
docs: Add sections for InputDevice and DeviceManager
docs: Add clutter_input_device_get_device_name()
tests: Print out the device details on motion
Always register core devices
device: Remove unused is_default member
win32: Experimental implementation of device support
tests: Print the device name, as well as its Id
x11: Fill out the :name property of the InputDevices
device: Add the :name property to InputDevice
x11: Store core devices on the X11 Backend singleton
device: Unset the cursor actor when leaving the stage
device: Add pointer actor getter
x11: Discard the LeaveNotify for off-stage ButtonRelease
device: Do not overwrite the stage for an InputDevice
event: Off-stage button releases have a click count of 1
event: Scroll events do not have click count
...
Added a "selection-bound" notify on clutter_text_clear_selection as it
changes the value.
Added utility function clutter_text_set_positions, in order to
change both cursor position and selection bound inside a
g_object_[freeze/thaw]_notify block
Added g_object_[freeze/thaw]_notify in other functions that changes
both cursor position and selection bound
Solves http://bugzilla.openedhand.com/show_bug.cgi?id=1955
ClutterStage has both set_key_focus() and get_key_focus() methods, but
there is no :key-focus property. This means that it is not possible to
get notifications when the key-focus has changes except by connecting to
both the ::key-focus-in and ::key-focus-out signals and do additional
bookkeeping.
http://bugzilla.openedhand.com/show_bug.cgi?id=1956
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
The TimeoutPool is not used by ClutterTimeline any more, so we need to
remove a sentence from its description. We also need to fix the gtk-doc
syntax errors.
Instead of assigning a new colour to each quad of a batch, the
rectangle debugging code now assigns a new colour to each batch so
that it can be used to visually see what is being batched. The colour
is stored in a global variable that is reset during cogl_clear. This
improves the chances that the same colour will be used for a batch in
the next frames to avoid flickering.
Instead of assigning a new colour to each quad of a batch, the
rectangle debugging code now assigns a new colour to each batch so
that it can be used to visually see what is being batched. The colour
is stored in a global variable that is reset during cogl_clear. This
improves the chances that the same colour will be used for a batch in
the next frames to avoid flickering.
When setting up the state for the vertex buffer,
enable_state_for_drawing_buffer tries to keep track of the highest
numbered texture unit in use. It then disables any texture arrays for
units that were previously enabled if they are greater than that
number. However if there is no texturing in the VBO then the max used
unit would be left at 0 which it would later think meant unit 0 is
still in use so it wouldn't disable it. To fix this it now initialises
the max used unit to -1 which it should interpret as ‘no units are in
use’ so it will later disable the arrays for all units.
Thanks to Jon Mayo for reporting the bug.
http://bugzilla.openedhand.com/show_bug.cgi?id=1957
When setting up the state for the vertex buffer,
enable_state_for_drawing_buffer tries to keep track of the highest
numbered texture unit in use. It then disables any texture arrays for
units that were previously enabled if they are greater than that
number. However if there is no texturing in the VBO then the max used
unit would be left at 0 which it would later think meant unit 0 is
still in use so it wouldn't disable it. To fix this it now initialises
the max used unit to -1 which it should interpret as ‘no units are in
use’ so it will later disable the arrays for all units.
Thanks to Jon Mayo for reporting the bug.
http://bugzilla.openedhand.com/show_bug.cgi?id=1957
In the example for clutter_actor_animate the "x" and "y" properties
are floats so they need to be passed float values in the var args
otherwise it will crash. There was also a missing comma.
There were some other minor problems with the behaviours example which
would cause it not to compile.
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.
