b8f92a6ce4
As event handling goes: 1) Events get generated and queued by the seat (from another thread in native, in the same thread in X11) 2) The MetaBackend gets those events and forwards them to Clutter via clutter_do_event() 3) The events get queued in the ClutterStage 4) At the time of processing a frame, the input events are processed, 5) Motion events are throttled, only the last is effectively handled 6) Events are filtered, wayland and WM handling happens here 7) Events maybe reach to clutter This commit moves 6 to happen between 2 and 3. The end result is that: - Throttling only applies to Clutter event handling, The wayland event forwarding bits will handle the event stream as soon as it comes, as timely as possible. - WM event handling is also unthrottled, but that's more of a side effect. - This all still happens on the main thread, so there's the possibility that other busy areas (e.g. relayout) temporarily block this event forwarding. - Sending events unthrottled inherently means more CPU, probably dependent on input devices' frequency. The impact is not measured. This should bring the best of both worlds with e.g. 1000Hz mice, wayland clients get unthrottled events, while GNOME Shell UI still behaves like it used to do. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915> |
||
|---|---|---|
| .gitlab/issue_templates | ||
| .gitlab-ci | ||
| clutter | ||
| cogl | ||
| data | ||
| doc | ||
| meson | ||
| po | ||
| src | ||
| subprojects | ||
| tools | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| check-style.py | ||
| config.h.meson | ||
| COPYING | ||
| HACKING.md | ||
| meson_options.txt | ||
| meson.build | ||
| mutter.doap | ||
| NEWS | ||
| README.md | ||
Mutter
Mutter is a Wayland display server and X11 window manager and compositor library.
When used as a Wayland display server, it runs on top of KMS and libinput. It implements the compositor side of the Wayland core protocol as well as various protocol extensions. It also has functionality related to running X11 applications using Xwayland.
When used on top of Xorg it acts as a X11 window manager and compositing manager.
It contains functionality related to, among other things, window management, window compositing, focus tracking, workspace management, keybindings and monitor configuration.
Internally it uses a fork of Cogl, a hardware acceleration abstraction library used to simplify usage of OpenGL pipelines, as well as a fork af Clutter, a scene graph and user interface toolkit.
Mutter is used by, for example, GNOME Shell, the GNOME core user interface, and by Gala, elementary OS's window manager. It can also be run standalone, using the command "mutter", but just running plain mutter is only intended for debugging purposes.
Contributing
To contribute, open merge requests at https://gitlab.gnome.org/GNOME/mutter.
It can be useful to look at the documentation available at the Wiki.
Coding style and conventions
See HACKING.md.
Git messages
Commit messages should follow the GNOME commit message
guidelines. We require an URL
to either an issue or a merge request in each commit. Try to always prefix
commit subjects with a relevant topic, such as compositor: or
clutter/actor:, and it's always better to write too much in the commit
message body than too little.
Default branch
The default development branch is main. If you still have a local
checkout under the old name, use:
git checkout master
git branch -m master main
git fetch
git branch --unset-upstream
git branch -u origin/main
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
License
Mutter is distributed under the terms of the GNU General Public License, version 2 or later. See the COPYING file for detalis.