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
