Enable animation updates from the GdkFrameClock whenever any timeline is
added to the ClutterMasterClockGdk. This may improve animation
smoothness (depending on the GDK backend in use) because it allows GDK
to tweak its frame timing for animation purposes.
https://bugzilla.gnome.org/show_bug.cgi?id=755357
This is how GdkFrameClock is meant to be used: the frame time is meant
to be queried from the GdkFrameClock within its frame signals, rather
from the system monotonic time source.
https://bugzilla.gnome.org/show_bug.cgi?id=755357
When removing the frame callback on the CoglOnscreen, we loose the ability
to get notified of swap events. This could leave us with a counter != 0
which leads to a deadlock situation after the next realize/draw cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=755014
If we call _clutter_stage_do_update() on a ClutterStage that isn't
mapped/visible, no GL command will be queued, and the Mesa/DRI2
implementation of SwapBuffers will do nothing. This causes
GLX_INTEL_swap_event to not be emitted by the X server because no swapping
has been requested through DRI2 and it eventually leads to a deadlock
situation in ClutterStageCogl because we're waiting for an event before we
start the next draw cycle.
This patch removes the non mapped stages from the list of stages to process.
This is consistent with a previous patch for the ClutterMasterClockGdk [1].
[1] : 5733ad58e5https://bugzilla.gnome.org/show_bug.cgi?id=755014
Setting up the sync_to_vblank in the MasterClock is a bit too late as
the MasterClock can be created after a StageWindow has been created
and realized (and therefore all of its Cogl/GL state setup already).
So move the setup to the backend, prior to any StageWindow creation.
https://bugzilla.gnome.org/show_bug.cgi?id=754938
Clutter still uses part of the deprecated stateful API of Cogl (in
particulart cogl_set_framebuffer). It means Cogl can keep an internal
reference to the onscreen object we rendered to. In the case of
foreign window, we want to avoid this, as we don't know what's going
to happen to that window.
This change sets the current Cogl framebuffer to a dummy 1x1
framebuffer if the current Cogl framebuffer is the one we're
unrealizing.
https://bugzilla.gnome.org/show_bug.cgi?id=754890
We're currently hooked to the "update" signal of the FrameClock. When
embedding Clutter inside GTK+ we want to have the layout phase of GTK+
to notify us the size of our stage.
This patch change to FrameClock signal we're listening to, to the
"paint" signal to make sure we've received the layout information from
GTK+, before painting. Otherwise we paint with a delay of one frame.
https://bugzilla.gnome.org/show_bug.cgi?id=754889
The commit 6cd24faaa5 (actor: Clean up
transform_stage_point()) changed the validation of the transformation
matrix to ignore the fraction part of the determinant. This caused
clutter_actor_transform_stage_point() to fail and return FALSE for
actors which scale was less than 1.
Previously the validation was ('det' being a float):
det = (RQ[0][0] * ST[0][0])
+ (RQ[0][1] * ST[0][1])
+ (RQ[0][2] * ST[0][2]);
if (!det)
return FALSE;
Semantically, the if statement expression '!det' is equivalent to
'det == 0', i.e. 'det == 0.0f'. Post cleanup patches, 'det' was turned
into a double, and the if statement was changed to:
if (CLUTTER_NEARBYINT (det) == 0)
return FALSE;
which, different from before, rounds the determinant to the nearest
integer value, meaning determinant in the range (-0.5, 0.5) would be
considered invalid.
This patch reverts this part to the old behavior, while, because of the
inexact nature of floating point arithmetics, allowing a bit more liberal
meaning of "equals to 0" than '== 0.0'.
https://bugzilla.gnome.org/show_bug.cgi?id=754766
When running on wayland, we might have our own subsurface
desynchronized from the foreign GdkWindow. It is important that we
report the size of the actually surface we're rendering to, otherwise
the logic in ClutterStage might discard resize operation that
resynchronize the subsurface with the stage's size.
https://bugzilla.gnome.org/show_bug.cgi?id=754697
For foreign windows this should be dealt with by the embedding
framework. In particular on Wayland with foreign windows, we might
want to create a subsurface and use the foreign window only for events
and frame clock synchronization.
https://bugzilla.gnome.org/show_bug.cgi?id=754697
Some operations like :
* resize
* show/hide
* set_title
* set_user_resizable
should be handled by the embedding framework, so disable them for
foreign windows.
https://bugzilla.gnome.org/show_bug.cgi?id=754671
When using Clutter embed inside a Gtk application, a stage might end
up realized but not visible. In this case we might discard doing any
kind of animation processing.
https://bugzilla.gnome.org/show_bug.cgi?id=754671
Just like GtkGrid, changing the orientation of a ClutterGridLayout does
not change the existing layout; the orientation property is only used as
a hint when adding new children.
We automatically switch the request mode of the container depending on
the GridLayout's orientation, but we need to keep track of the request
mode during allocation, so that we don't get out of sync if the user
changed the request mode after adding the layout manager.
This change also brings us closer to the code in GtkGrid.
We use the orientation of the grid to get the preferred size of the
layout, but we should be using the orientation of the request instead.
The preferred width has an orizontal orientation, and the preferred
height has a vertical orientation.
This allows us to refactor the get_preferred_* implementation into a
separate function.
We are currently using deprecated/Clutter-specific API in Cogl to
retrieve the XVisualInfo associated with the (E)GLX context. Cogl 1.21.2
added new CoglRenderer API to achieve the same result.
We want to use the Cogl GL3 driver, if possible, and then go through a
known list of Cogl drivers, before giving up and using COGL_DRIVER_ANY.
Based on original patch from Emmanuele Bassi.
We have to create and tear down the whole context when trying
out the drivers though because the extension checks do not happen
until cogl_context_init.
https://bugzilla.gnome.org/show_bug.cgi?id=742678
The ClutterX11XInputEventTypes enumeration has been unused inside
Clutter for the past 4 years and a half, since we switched to the
XInput 2 API.
The enumeration itself has always been private, and nobody should
have used it in the first place, but if something breaks, we can
revert this commit.
They should be part of the backend-specific API.
The only backend that has an enumeration type is the X11 one, and it's
small, so we can simply put it there.
This is not an ABI change: the backend-specific symbols are still in
the same SO. You'll be required to import clutter-x11.h to have access
to the GType method at the source level, whereas before just importing
clutter.h would have sufficed. The only user of that enumeration was a
function declared in clutter-x11.h, anyway.
We're inconsistently using the NAMESPACE variable instead of passing
the --identifier-prefix and --symbol-prefix command line arguments to
the introspection scanner.
Now that we can warn about deprecated macros, we should finally do it
for the old, non-namespaced key symbol macros that we've been stringing
along since the 1.0 days.
We want to be able to deprecate macros, but right now the best we can do
is to wrap them with things like:
#ifndef CLUTTER_DISABLE_DEPRECATED
# define A_MACRO_I_WANT_TO_DEPRECATE ...
#endif
Which requires adding a new symbol to the build, and will cause a build
error instead of a compiler/pre-processor warning.
Fortunately, we can use the _Pragma() keyword introduced by C99 and
supported by GCC to add a warning to the output, while leaving the macro
itself intact.
GCC does not have a "deprecated" pragma, so we have to use a generic
warning; this also means we cannot do nifty things like concatenating
strings and the like, as we do for the "deprecated" attribute.
The macro deprecation symbol should have the same affordances as the
function deprecation one, and evaluate to nothing if the required
version is lower than the current version; or if the global toggle for
deprecation warnings is in effect.
