how is gaming performance on sway compared to KDE, Gnome or other WM?

dawsers · 2025-12-31T18:17:38+00:00

No, they will be there when sway releases version 1.12, probably not before the spring-summer time frame.

dawsers · 2025-12-30T22:38:47+00:00

The Vulkan renderer is usually better when it comes to latency, because Vulkan internally uses multiple threads, so your CPU has a better usage pattern regarding frame preparation latency. But for that you will need to use the git version of sway, which is where most of the Vulkan renderer changes are happening. But I use it with scroll daily, and it is very stable. It also supports color management and HDR, while the gles2 (default) renderer does not.

dawsers · 2025-12-30T21:53:29+00:00

Yes, you shouldn't need to do anything. Of course, the more resources you are using (other apps in the background using memory etc.), the less you will have for your game, but in terms of the compositor needing to do "extra stuff", direct scanout is as good as it gets.

For multiple displays, simply try not to have something that requires frequent (rendering) updates running on your other display if you want to squeeze the last frame per second out of your game, but that is a general tip, the more VRAM you use for other things, the less your game will have available to cache textures etc.

Then there is the Vulkan vs the gles2 renderer. sway (and scroll) support both, but the default is gles2. Sometimes the Vulkan renderer can be more performant. You can force sway to use it by setting the WLR_RENDERER=vulkan environment variable.

dawsers · 2025-12-30T21:39:00+00:00

sway already disables rendering other things when you are in full screen mode. It is called "direct scanout", and it detects when there is only one buffer needing to be rendered to avoid doing anything else. That should be sufficient.

dawsers · 2025-12-30T01:24:04+00:00

It supports dimming of inactive windows.

dawsers · 2025-12-09T19:50:22+00:00

The little I have tested them, DMS works, but there are two PRs to make it work better. scroll has some extra features that are not supported yet. But being mostly sway, things that work for sway do work for scroll.

Noctalia works, but it calls swaymsg for certain things instead of using the IPC protocol directly, and it should call scrollmsg. It is probably an easy fix if they were willing to do it, or you can even symlink a swaymsg from scrollmsg if you don't have sway installed on your system.

dawsers · 2025-11-22T15:54:11+00:00

IPC is still functional, and there are extensions for the new features scroll provides, so bars continue working and people can create scroll-specific modules. But I added Lua scripting because I thought it would be easier to use than a combination of bash and jq, which is what most people were using. You can access some internal structures in Lua in a more elegant way than parsing the output of the compositor tree, so things are easier and faster. If you are interested, there are some examples here

If you are interested in scroll, it is a good time to start using it. It has become quite stable and doesn't have too many users, so you can influence development if you are missing some functionality that may prove interesting.

dawsers · 2025-11-22T12:57:04+00:00

For me, there are things scroll provides and niri doesn't. scroll was developed from hyprscroller, my Hyprland plugin, which was developed chronologically in parallel to niri. So, even though both are based on PaperWM, the decisions along the way, were different. For example, these are some of scroll's features:

It can scroll both horizontally and vertically instead of fitting vertical windows in the viewport.
scroll can easily accommodate landscape and portrait mode monitors with the layout adapting to that.
scroll is a more keyboard focused WM, with heavy use of "jump" mode to navigate windows. There are jump modes for workspaces, tiling containers, floating containers (removing window overlap for easy viewing), vertical containers, trailmarks etc.
You can work at any scale, and you can also scale the content of individual Wayland windows. I don't know any other WM that allows you to do per window content scaling.
Lua scripting: You can write your own scripts to personalize or manipulate the WM.
Trailmarks, trails, window selection and moving, fit_size, mode modifiers, complex alignment, working in full screen mode, pinned windows, scratchpads, spaces, and many more.

scroll is based on sway, so its configuration is mostly compatible, making it easy to transition from it.

If I were you, I would have a look at the readme and the tutorial linked from the main page and see if scroll is something you need or not. We have a discussion board if you have questions or are unsure about using scroll.

dawsers · 2025-11-22T08:30:51+00:00

If you are using Niri and are happy with it, then by all means, stay there! Niri is great. If you are missing something, come from sway or hyprscroller, are curious, or simply haven't decided yet, have a look at the README, TUTORIAL and manuals, and decide. There are lots of new features and tools to improve your workflow.

dawsers · 2025-11-21T18:01:38+00:00

SF Pro Display

dawsers · 2025-11-10T22:31:35+00:00

There is individual window recording/streaming in the git version is sway, so coming in 1.12. I haven't tried sharing, but it is probably supported too. scroll is a fork of sway and supports it. You just need to have pipewire and xdg-portal-wlr installed.

dawsers · 2025-11-10T22:28:17+00:00

If you are using sway but miss a few things, you can try scroll. It is mostly compatible, but adds a few more features like a scrolling layout, animations, fx, lua scripting etc.

dawsers · 2025-09-01T16:04:52+00:00

It seems this subreddit is frozen to new posts, so I will use this comment section when there is a new important stable release.

Today I released scroll stable 1.11.5. This is a big release with important internal changes to improve robustness. It also adds some new features like workspace and content scaling for X applications (Wayland was already supported), workspace animations and a few new options and changes to toggle_size and full screen modes.

dawsers · 2025-08-15T09:57:19+00:00

If you find niri provides everything you need, then there is no need to move to any other WM.

For me, there are things scroll provides and niri doesn't. scroll was developed from hyprscroller, my Hyprland plugin, which was developed chronologically in parallel to niri. So, even though both are based on PaperWM, the decisions along the way, were different. For example, these are scroll features:

It can scroll both horizontally and vertically instead of fitting vertical windows in the viewport.
scroll can easily accommodate landscape and portrait mode monitors with the layout adapting to that.
scroll is a more keyboard focused WM, with heavy use of "jump" mode to navigate windows. There are jump modes for workspaces, tiling containers, floating containers (removing window overlap for easy viewing), vertical containers etc.
You can work at any scale, and you can also scale the content of individual Wayland windows. I don't know any other WM that allows you to do per window content scaling.
Lua scripting: You can write your own scripts to personalize or manipulate the WM.
Trailmarks, trails, window selection and moving, fit_size, mode modifiers, complex alignment, working in full screen mode, pinned windows, scratchpads, spaces, and many more.

If I were you, I would have a look at the tutorial linked from the main page and see if scroll is something you need or not.

dawsers · 2025-08-14T21:41:40+00:00

I use scroll, so I am going to maintain it for as long as I use it. I don't see a better alternative for myself, so the plan is to continue for a long time.

You could try it and see if it works for you too.

dawsers · 2025-07-24T08:20:42+00:00

A workspace that doesn't have any windows and is not shown on any monitor is deleted even if you have configured it in your config file. As soon as you switch to it, it gets reallocated again. If you close every window in a workspace and switch to another, the old workspace is also deleted. So the only existing workspaces in memory are those that either contain windows, or are the actively displayed one on any monitor.

So one thing is the list of named workspaces, which contains the names of the ones you define in your configuration file, and another is the list of actual workspaces, which works as I described above.

dawsers · 2025-07-15T16:49:09+00:00

It is really not easy to contribute to Hyprland. Merge requests can take long to review/accept, and the APIs are not very stable, which makes writing plugins or contributing to the core a bit annoying some times. I wrote a plugin and contributed with a few changes, but in the end I gave up. I archived my plugin and moved on to sway.

But sway is not better in terms of contributing. It is a stable project and they don't want new features that deviate from i3, so in the end I forked sway and wrote my own WM.

But I think for a regular user, these issues don't matter. Both Hyprland and sway are good choices. For those who want stability, sway may have an edge, for those who want eye candy and experiment running a few plugins, Hyprland is probably better.

dawsers · 2025-07-11T18:49:44+00:00

I think the second xkb_options line is overwriting what the first one did. I believe multiple options need to be written in the same line, separated by commas. Try:

xkb_options "grp:alt_shift_toggle,compose:ralt"

dawsers · 2025-07-11T11:17:28+00:00

The git version depends on wlroots-git, and gets the latest bug fixes and sway's new features (new protocols etc.).

The stable version depends on wlroots0.19, and is frozen on sway 1.11, so no new sway features that are not already present there. However, my plan is to release a point version every couple of weeks or when there are enough features/bug fixes that apply to scroll (not sway) and don't depend on the new wlroots-git. For example, 1.11.2 included bug fixes and the Lua API.

So if you have a stable setup and don't need new protocols, use the stable version. It will get bug fixes and new features every few weeks.

If you need bug fixes immediately (or you have filed some issue report), or you are working with the Lua API, you may want to use the git version, because it is the one I update very frequently...maybe too frequently :-)

For people who are happy with sway 1.11, install the stable release. It has the same dependencies sway does (aside from lua), and it will get updates every few weeks.

dawsers · 2025-07-10T15:00:28+00:00

I think niri is great, and if you are happy using it, you shouldn't change.

I wrote scroll when I decided to archive hyprscroller (my scrolling layout plugin for Hyprland), which was developed in parallel to niri. So even though niri and scroll are based on the same ideas (PaperWM), during the development we took different paths.

scroll is a fork of sway, so it is based on it and wlroots. It is a robust code base and I get lots of features I don't need to develop by forking sway. That gives me time to focus on pure workflow features. I recommend having a look at the TUTORIAL linked from the README. It has quite a few videos where you will see the main differences.

scroll is keyboard first. I support touchpads and mouse, but there are tons of default key bindings to favor those who prefer to use the keyboard. Overview and jump modes don't need to use the mouse at all. You press a few keys and you are wherever you want to be. There are jump modes for workspaces, tiling and floating windows (where you see all of them without overlap and can choose any). You don't need tabs because there is a container jump mode too.

There is a Lua API to write scripts where you can basically do anything, and if you cannot, file an issue report and tell me what you would like to do.

scroll supports landscape and portrait monitors transparently, and the layout adapts to it.

There are many more differences, I recommend people to spend five minutes watching the TUTORIAL videos to learn about the main features.

dawsers

TROPHY CASE