It was not the lack of forcing the shadow fb that caused slowness, but
rather due to the method the shadow fb content was copied onto the
scanout fb. With 'clutter: Use cogl_blit_framebuffer() for shadow FB'
we'll use a path that shouldn't be slow when copying onto the scanout
fb.
Also 437f6b3d59f2102f5974bfc430176725f2ed67c2 accidentally enabled
shadow fb when using hw accelerated contexts, due to the cap being set
to 1 in majority of drivers. While the kernel documentation for the
related field says "hint to userspace to prefer shadow-fb rendering",
the name of the hint when exposed to userspace is
DRM_CAP_DUMB_PREFER_SHADOW, thus should only be taken into consideration
for dumb buffers, not rendering in general.
This reverts commit 437f6b3d59f2102f5974bfc430176725f2ed67c2.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/818
The commit 'renderer/native: Use shadow fb on software GL if preferred'
attempted to force using a shadow fb when using llvmpipe in order to
speed up blending, but instead only did so when llvmpipe AND the drm
device explicityl asked for it.
Now instead always force it for llvmpipe and other software rendering
backends, and otherwise just query the drm device (i.e.
DRM_CAP_DUMB_PREFER_SHADOW).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/807
Since the recent clutter-content work, legacy scaling (in contrast
to the new stage-view-scaling) only applies to surfaces that belong
to a window. This broke scaling of DnD surfaces.
As a workaround, apply the same scaling on DnD-surface-actors until
we use stage-view-scaling by default and can remove this again.
Also: small corrections of geometry calculation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
This allows us to implement more sophisticated logic for the different
cases. For DnD surfaces, use the geometry scale of the monitor where
the pointer is, instead of incorrectly assuming '1' as it was before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
The meta_display_update_focus_window() call has indirect dependencies
on the X11 focus window, in order to determine the correct focus window
on the Wayland side (i.e. may turn out NULL with certain X windows).
In order to have the right x11_display->focus_xwindow there, we should
perform first the focus update on the X11 display.
Fixes focusing of Java applications, as those don't seem to go through
_NET_ACTIVE_WINDOW.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/819
With the addition of the locate-pointer special keybinding (defaults to
the [Control] key), we have now two separate special modifier keys which
can be triggered separately, one for the locate-pointer action and
another one for overlay.
When processing those special modifier keys, mutter must ensure that the
key was pressed alone, being a modifier, the key could otherwise be part
of another key combo.
As result, if both special modifiers keys are pressed simultaneously,
mutter will try to trigger the function for the second key being
pressed, and since those special modifier keys have no default handler
function set, that will crash mutter.
Check if the handler has a function associated and treat the keybinding
as not found if no handler function is set, as with the special modifier
keys.
https://gitlab.gnome.org/GNOME/mutter/issues/823
The `process_event()` would check for a existing keybinding handler and
abort if there is none, however the test is done after the handler had
been accessed, hence defeating the purpose of the check.
Move the check to verify there is an existing keybinding handler before
actually using it.
https://gitlab.gnome.org/GNOME/mutter/issues/823
There were multiple bugs present after the ClutterContent transition.
Refactor `get_image` to:
- always assume surface coordinates for the clip
- return a cairo_surface in buffer size
- make the offscreen path take size arguments, so we can
easily change the assumption in get_image
- fix some clipping bugs on the way
https://gitlab.gnome.org/GNOME/mutter/merge_requests/758
Some drivers expose EGL_EXT_image_dma_buf_import_modifiers so you can
query supported formats, but don't support any modifiers. Handle this by
treating it like DRM_FORMAT_MOD_INVALID.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/782
Instead of open coding the X11 focus management in display.c, expose
it as a single function with similar arguments to its MetaDisplay
counterpart. This just means less X11 specifics in display.c.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
MetaDisplay and MetaX11Display focus windows are slightly decoupled,
we cannot rely here on the MetaDisplay focus to be updated yet. We
however know the X Window that got focused, so lookup the corresponding
MetaWindow (and client X window) from it.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
We have a "setup" phase, used internally to initialize early the x11
side of things like the stack tracker, and an "opened" phase where
other upper parts may hook up to. This latter phase is delayed during
initialization so the upper parts have a change to connect to on
plugin creation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/771
When starting standalone mutter and running using the native backend, we
always fall back on using the us pc105 keyboard layout. This can be very
frustrating if one is used to using some other keyboard layout, such as
dvorak, causing keyboard fumbling everytime when doing something with
standalone mutter.
Avoid this involuntary fumbling by having the default plugin query
localed what layout the user has actually configured the machine to
operate using. It doesn't add any keymap selection user interface, so
it'll always use the first one it encounters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/787
The commit f2f4af0d50ba9f2d36cf225162a30928f55d7bd6 missed one situation
where mutter does things differently, i.e. changes what surface actor is
associated with a given window actor: reparenting a Xwayland window when
changing whether it is decorated.
To summarize, there are three types of window actors:
X11 window actors - directly tied to the backing X11 window. The
corresponding surface actor is directly owned by the window actor and
will never change.
Wayland window actors - gets its surface actor from MetaWaylandSurface
at construction. A single MetaWaylandSurface may create and destroy
multiple window actors over time, but a single window actor will never
change surface actor.
Xwayland window actors - a mix between the above two types; the window
corresponds to the X11 window, and so does the window actor, but the
surface itself comes from the MetaWaylandSurface.
Normally when a X11 window is unmapped, the corresponding MetaWindow is
unmanaged. With Xwayland, this happens indirectly via the destruction of
the wl_surface. The exception to this is windows that are reparented
during changing their decoration state - in this case on plain X11, the
MetaWindow stays alive. With Xwayland however, there is a race
condition; since the MetaWindow is tied to the wl_surface, if we receive
the new surface ID atom before the destruction of the old wl_surface,
we'll try to associate the existing MetaWindow and MetaWindowActor with
the new wl_surface, hitting the assert. If the surface destruction
arrives first, the MetaWindow and MetaWindowActor will be disposed, and
the we wouldn't hit the assert.
To handle this race gracefully, reinstate handling of replacing the
surface actor of an existing window actor, to handle this race, as it
was handled before.
Eventually, it should be reconsidered whether the MetaWindow lifetime is
tied to the wl_surface or if it should be changed to be consistent with
plain X11, as this re-exposes another bug where the X11 client and
mutter will enter a feedback loop where the window is repeatedly
remapped. See https://gitlab.freedesktop.org/xorg/xserver/issues/740.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/709https://gitlab.gnome.org/GNOME/mutter/merge_requests/773
When using xdg-output v3 or later, the Wayland compositor does not send
xdg_output.done events which are deprecated.
Instead, it should send a wl_output.done event for the matching
wl_output.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/771
When suspending, the devices are removed and the virtual device
associated with the corresponding core pointer is disposed.
Add the pointer accessibility virtual device to the core pointer
on resume to restore pointer accessibility on resume if enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/761
When starting a DnD operation, mutter would remove keyboard focus from
the client, only to restore it on the data offer destroy.
However, if the DnD fail, the keyboard focus is not restored, leaving
the user unable to type in the focused window, even after clicking in
the window.
That issue would show only on first attempt, as further DnD attempts
would destroy the previous data offer which would also restore the
keyboard focus.
Make sure we restore the keyboard focus on drag end as well.
https://gitlab.gnome.org/GNOME/mutter/issues/747
On drag start, `data_device_start_drag()` issues a keyboard grab, which
in turn will unset the current input focus.
There is not need to unset the input focus in `data_device_start_drag()`
as this is redone in `meta_wayland_keyboard_start_grab()`
https://gitlab.gnome.org/GNOME/mutter/issues/747
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
Add a function to check whether a point is inside a quadrilateral
by checking the cross product of vectors with the quadrilateral
points, and the point being checked.
If the passed quadrilateral is zero-sized, no point is ever reported
to be inside it.
This will be used by the next commit when comparing the transformed
actor vertices.
[feaneron: add a commit message and remove unecessary code]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
If window decoration is modified within a short period of time, mutter
sometimes starts processing the second request before the first
UnmapNotify event has been received. In this situation, it considers
that the window is not mapped and does not expect another UnmapNotify /
MapNotify event sequence to happen.
This adds a separate counter to keep track of the pending reparents. The
input focus is then restored when MapNotify event is received iff all
the expected pending ReparentNotify events have been received.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
Threaded swap wait was added for using together with the Nvidia GLX
driver due to the lack of anything equivalent to the INTEL_swap_event
GLX extension. The purpose was to avoid inhibiting the invocation of
idle callbacks when constantly rendering, as the combination of
throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
source having higher priority than the default idle callback sources
meant they would never be invoked.
This was solved in gbz#779039 by introducing a thread that took care of
the vsync waiting, pushing frame completion events to the main thread
meaning the main thread could go idle while waiting to draw the next
frame instead of blocking on glxSwapBuffers().
As of https://gitlab.gnome.org/GNOME/mutter/merge_requests/363, the
main thread will instead use prediction to estimate when the next frame
should be drawn. A side effect of this is that even without
INTEL_swap_event, we would not block as much, or at all, on
glxSwapBuffers(), as at the time it is called, we have likely already
hit the vblank, or will hit it soon.
After having introduced the swap waiting thread, it was observed that
the Nvidia driver used a considerable amount of CPU waiting for the
vblank, effectively wasting CPU time. The need to call glFinish() was
also problematic as it would wait for the frame to finish, before
continuing. Due to this, remove the threaded swap wait, and rely only on
the frame clock not scheduling frames too early.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
Related: https://gitlab.gnome.org/GNOME/mutter/issues/700
[jadahl: Rewrote commit message]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/602
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
If an application provides its window icon via wmhints, then mutter
loads the pixmap specified by the application into a cairo xlib surface. When
creating the surface it specifies the visual, indirectly, via an XRender
picture format.
This is suboptimal, since XRender picture formats don't have a way to specify
16bpp depth, which an application may be using.
In particular, applications are likely to use 16bpp depth pixmaps for their
icons, if the video card offers a 16bpp framebuffer/root window.
This commit drops the XRender middleman, and just tells cairo a visual to use
directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/715
This reverts commit b95d7e8276e31a3414ec4d5ee13191c3f253fa1c.
It's poisoning cairo's GC cache with a GC that has the wrong
colordepth, leading to a crash in unrelated code later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/715
