When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
It's not always clear how the dma-buf functions work (e.g. where memory
is allocated) without actually going in-depth in the code. This just
adds a few commments to more quickly gain understanding.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/871
Checking the leds is not really accurate, since some devices have mode
switch buttons without leds. Check in the button flags whether they are
mode switch buttons for any of ring/ring2/strip/strip2, and return the
appropriate group.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/952
While most of the code to compute a window's layer isn't explicitly
windowing backend specific, it is in practice: On wayland there are
no DESKTOP windows(*), docks(*) or groups.
Reflect that by introducing a calculate_layer() vfunc that computes
(and sets) a window's layer.
(*) they shall burn in hell, amen!
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
Most of the layer computation that the stack does actually depends
on the windowing backend, so we will move it to a vfunc.
However before we do that, split out the bit that will be shared.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
When a window that should be stacked above another one is placed in a lower
layer than the other window, we currently allow promoting it to the higher
layer when it has a "transient type". We should do the same when the window
is an actual transient of the other window.
This is particularly relevant for wayland windows, where types play a
much smaller role: Transient windows like non-modal dialogs (and since
commit 666bef7a, popup windows as well) currently end up underneath their
always-on-top parent.
https://gitlab.gnome.org/GNOME/mutter/issues/587
This was wrongly introduced in 75cffd0ec4. As the comment above explains, we
only want to queue redraws in response to surface/buffer damage.
This triggered a full redraw when using DMA buffers on Wayland as we currently
create a new texture on every buffer_attach(), breaking partial invalidation.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/947
There might be some inconsistent event for which we don't have a known
source device.
In the current state we don't handle them and we could crash when getting
the current device tool.
So, add an utility function that retrieves the source device for an event
that warns if no device is found, and use this for Motion, Key and Button
events.
In case we don't have a valid source in such case, just return early instead
of trying to generate invalid clutter events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/823
Add an assert that we don't have a MetaWindow::monitor pointer that
points to an old MetaLogicalMonitor. After this, and the other
monitors-changed callbacks have been called, the old MetaLogicalMonitor
will be destoryed, thus if we didn't update the pointer here, we'll
point to freed memory, and will eventually crash later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/929
We do check the clip area as an optimization to know which input devices
might need updating state after a relayout (Assuming that if a device is
under a non-painted area, it's actor beneath didn't change).
Use the clip region for this, and drop the last usage of the clip region
bounds.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/867
This commit was split out from `cleanup: Use g_clear_signal_handler()
where possible` as it fixes an actual signal leak and should therefore
get backported to stable releases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
On wl_data_source destruction we used to indirectly unset the DnD selection
owner via the wl_resource destructor triggering the destruction of the
MetaWaylandDataSource, which would be caught through the weak ref set by
the MetaWaylandDragGrab.
This works as long as the grab is held, however we have a window between
the button being released and the drop site replying with
wl_data_offer.finish that the MetaWaylandDataSource is alive, but its
destruction wouldn't result in the call chain above to unsetting the DnD
source.
In other selection sources, we let the MetaWaylandDataDevice hold the
"ownership" of the MetaWaylandDataSource, and its weak ref functions unset
the respective MetaSelection owners. Do the same here, so the
MetaWaylandDataSource destruction is listened for all its lifetime.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/591
This is wrong for both clipboard and DnD, as the selection source
will still be able to focus another surface, and churn another
wl_offer.
We should just detach the data offer from the data source in this
case, and let the source live on. However, we should still check
that there is a source and an offer to finish DnD, do that when
handling the drop operation instead.
https://gitlab.gnome.org/GNOME/mutter/issues/591
Those were used to signal clipboard ownership around, but that got
replaced by MetaSelection and friends. These signals are no longer
listened on, so can be safely removed.
https://gitlab.gnome.org/GNOME/mutter/issues/591
