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
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
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>
The code is generally wrong, and does not work. We need to skip the
GdkWindow creation when we have a foreing window, but we still need to
create the Cogl onscreen buffer and connect it to the GdkWindow's native
resource.
The Clutter backend split is opaque enough that should allow us to just
build all possible backends inside the same shared object, and select
the wanted backend at initialization time.
This requires some work in the build system, as well as the
initialization code, to remove duplicate functions that might cause
conflicts at build and link time. We also need to defer all the checks
of the internal state of the platform-specific API to run-time type
checks.
Previously, the Cogl backend was at times a subclass of the X11
backend, and at times a standalone one. Now it is the other way
round, with GDK and X11 backends providing the concrete classes,
layered on top of the generic Cogl backend. A new EglNative backend
was introduced for direct to framebuffer rendering. This greatly
simplifies the API design (at the expense of some casts needed)
and reduces the amount of #ifdefs, without duplicating code.
https://bugzilla.gnome.org/show_bug.cgi?id=657434
This commit introduces a new flavour for Clutter, that uses GDK
for handling all window system specific interactions (except for
creating the cogl context, as cogl does not know about GDK), including
in particular events. This is not compatible with the X11 (glx)
flavour, and this is reflected by the different soname (libclutter-gdk-1.0.so),
as all X11 specific functions and classes are not available. If you
wish to be compatible, you should check for CLUTTER_WINDOWING_X11.
Other than that, this backend should be on feature parity with X11,
including XInput 2, XSettings and EMWH (with much, much less code)
https://bugzilla.gnome.org/show_bug.cgi?id=657434
