Since g_array_append_val isn't smart enough to do a proper upcast, we
have to do it manually, lest we get junk.
This fixes various RAISE_ABOVE: window not in stack: 0x8100c8003
warnings that appear on 32-bit systems.
Just like we do for _NET_WM_MOVERESIZE messages on X11, consider
wayland client move/resizes as "frame actions" so that the same
constraints are applied to them, in particular the titlebar visibility
constraint.
https://bugzilla.gnome.org/show_bug.cgi?id=748819
ClutterActor should warn if a user tries to add or remove an actor to,
and from, itself on the scene graph.
Clutter will likely crash, or warn way down the line, but if we can make
debugging simpler then we should.
In order for the native cursor renderer to be able to create a hw
cursor in response to wl_pointer.set_cursor(), keep a private use-count
and reference to the active buffer, stopping it from being released
until it is consumed, replaced, or the surface is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
Whether a surface needs to keep the committed wl_buffer un-released
depends on what role the surface gets assigned to. For example a cursor
role may need an unreleased shm buffer in order to create a hw cursor from
it.
In order to support this, keep a separate reference and use count to
the buffer on behalf of the in the future assigned role, and release
those references after the surface was assigned a role. A role that
needs its own references and use counts, must in its assign function
make sure to add those.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
Each wl_surface.commit with a newly attached buffer should result in
one wl_buffer.release for the attached buffer. For example attaching
the same buffer to two different surfaces must always result in two
wl_buffer.release events being emitted by the server. The client is
responsible for counting the wl_buffer.release events and be sure to
have received as many release events as it has attached and committed
the buffer, before reusing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
We can detect that these windows are already fully opaque, so allow them
to unredirect. Allows unredirecting Totem during video playback, giving
a significant speed boost.
This target is set whenever DnD moves towards an area between surfaces.
Although no offer is set and data is actually not read, drag sources
offering this mimetype will be able to behave just like they used to
do in X11.
https://bugzilla.gnome.org/show_bug.cgi?id=762104
We want some initial processing, even if the current focus didn't change.
This could be for example the case of starting DnD too close to the window
edge and out of it. At the point start_drag() is called, the current
pointer focus is already NULL, so set_focus() would simply bail out here.
https://bugzilla.gnome.org/show_bug.cgi?id=762104
On the X11 backend we don't track the pointer position in
priv->current_x/y which remain set to zero. That means we never set
the clutter stage cursor if point 0,0 isn't covered by any monitor
since we return early.
Commit 4bebc5e5fa introduced this to
avoid crashing on the prepare-at handlers when the cursor position
doesn't fall inside any monitor area but we can handle that higher up
in the stack. In that case, the sprite's scale doesn't matter since
the cursor won't be shown anyway so we can skip setting it.
https://bugzilla.gnome.org/show_bug.cgi?id=763159
We currently rely only on MetaWindowActor to update the mask
texture. This isn't good enough since we might get asked to use the
mask (e.g. via meta_shaped_texture_get_image() ) after having a new
texture size but before MetaWindowActor decides to update the mask in
which case we might crash since cogl_texture_new_from_sub_texture()
might fail with an early return such as
Cogl-CRITICAL **: cogl_sub_texture_new: assertion 'sub_x + sub_width
<= next_width' failed
https://bugzilla.gnome.org/show_bug.cgi?id=762639
This commits adds a gtk_surface.present request and its implementation.
The timestamp is assumed to be from some input event that the client
responded to. The timestamps we deal with when managing windows will
usually come from two different clocks: CLOCK_MONOTONIC if they come
from libinput/evdev, or CLOCK_MONOTONIC_COARSE if they come from the
X server.
Luckily these are quite similar, the difference beeing that the X server
timestamps having lower resolution, so we can just pass the timestamps
no matter where they came from and it'll most likely work fine, except
for the race condition described in bug 756272 which might happen here
too until it is properly fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=763295
