The X11 part of the GDK backend takes into account the scaling factor of its
window when resizing the underlying X11 objects. We need to do the same for
Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=755245
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
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
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
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.
Certain crossing modes notify about synthesized events, where
the pointer didn't really leave the window. Unsetting the stage
from the device at that time is incorrect, and will leave all
remaining touches unable to pick coordinates, so silently eaten
away.
https://bugzilla.gnome.org/show_bug.cgi?id=750496
Straight from Cogl.
This allows us to propagate the GdkVisual Cogl and Clutter use to
embedding toolkits, like GTK+.
The function is annotated as being added to the 1.22 development
cycle because it will be backported to the stable branch, so that
downstream developers can package up a version of Clutter that does
not crash on nVidia.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
GDK 3.16 started selecting different visuals, to best comply with the
requirements for OpenGL, and this has broken Clutter on GLX drivers that
are fairly picky in how they select visuals and GLXFBConfig.
GDK selects GLXFBConfig that do not include depth or stencil buffers;
Cogl, on the other hand, needs both depth and stencil buffers, and keeps
selecting the first available visual, assuming that the GLX driver will
give us the best compliant one, as per specification. Sadly, some
drivers will return incompatible configurations, and then bomb out when
you try to embed Clutter inside GTK+, because of mismatched visuals.
Cogl has an old, deprecated, Clutter-only API that allows us to retrieve
the XVisualInfo mapping to the GLXFBConfig it uses; this means we should
look up the GdkVisual for it when creating our own GdkWindows, instead
of relying on the RGBA and system GdkVisuals exposed by GDK — at least
on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
In order to do device matching we need to propagate more information,
like the device_id (only on X11 with the XInput2 extension enabled),
the vendor id, and the product id.
https://bugzilla.gnome.org/show_bug.cgi?id=747951
When defining clutter_stage_gdk_update_foreign_event_mask, check for the
same macros as when actually using it.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
It could happen that gdk_screen_get_setting fails to retreive
Gdk/WindowScalingFactor which leads to the following warnings when
clutter_init is called:
GLib-GObject-WARNING **: value "0" of type 'gint' is invalid or out of range for property 'window-scaling-factor' of type 'gint'
GLib-GObject-WARNING **: value "0" of type 'gint' is invalid or out of range for property 'dnd-drag-threshold' of type 'gint'
https://bugzilla.gnome.org/show_bug.cgi?id=749256
Slightly edited to fix up whitespace issues.
Edited-by: Emmanuele Bassi <ebassi@gnome.org>
While each stage has at most a GdkFrameClock, the same GdkFrameClock
instance may drive multiple stages per frame. This means that the
mapping between a GdkFrameClock and a ClutterStage is a 1:M one, not a
1:1.
We should store a list of stages associated to each frame clock
instance, so that we can iterate over it when we need to update the
stages.
This commit fixes redraws of applications using multiple stages,
especially when using clutter-gtk.
Nobody has been compiling Clutter with profiling enabled in a long time.
UProf itself hasn't been updated in 5 years, and it still depends on
deprecated components like dbus-glib, with no port to GDBus in sight.
The profiling code was moderately useful in the past, but these days
it's probably better to profile Cogl than Clutter itself; timing
information can be extracted by the timestamp on each diagnostic message
that is now available by default in the CLUTTER_NOTE macro, and we can
add ad hoc counters where needed.
If gdk event retrieval has been disabled and gdk's backend is wayland
we must also disable cogl's wayland event dispatching otherwise cogl
will try to dispatch wayland events itself which blocks the main
loop.
https://bugzilla.gnome.org/show_bug.cgi?id=744058
When an application sets the scaling factor manually we should mark it as fixed
and not override it when the xsettings change. This matches GDKs behaviour.
In order for this to work we cannot use the same path when setting the value
internally so introduce a _clutter_settings_set_property_internal and use it
for that.
https://bugzilla.gnome.org/show_bug.cgi?id=735244
All backends follow the same pattern of queueing events first in
ClutterMainContext, then copying them to a ClutterStage queue and
immediately free them. Instead, we can just pass ownership of events
directly to ClutterStage thus avoiding the allocation and copy in
between.
https://bugzilla.gnome.org/show_bug.cgi?id=711857
Since commit 4543ed6ac3 in Cogl, Cogl will now try to consume
Windows message itself. This doesn't really cause any problems because
both message loops just call DispatchMessage which will cause the
message to be routed through Clutter's window procedure either way.
However, it's not great to have two sources listening for messages so
this patch disables Cogl's message retrieval.
https://bugzilla.gnome.org/show_bug.cgi?id=701356
