Sway: Cursor has a subtle lag compared to i3 or Gnome on Wayland

[neon64]

When using sway, the cursor moves slightly unnaturally and with a touch of lag which, although it is hardly visually noticeable, makes using sway just feel wrong and inefficient. Its quite possible this is an issue in the underlying wlc library, but after a quick search found no open issues, I thought I'd open one here.

Is this something others are experience too? For the record I am using a MacBook Pro 2010. Although it is subtle, it makes even the most basic of tasks like selecting text difficult.

[ddevault]

Try configuring your input device? man 5 sway-input. Try a flat accel_profile.

[neon64]

I'm afraid I've already tried a multitude of options like that. Could it be to do with the fact that Sway has a software cursor thus its slightly slower?

[kkliebersbach]

Bump, I can reproduce this issue.

[yegorius]

Yes, this bothers me too. It feels as if cursor was rendered at 30FPS.

[mikkeloscar]

My guess is this is in wlc, did you try to compare it to orbment?

[ghost]

If you are on a laptop, can you try to see if you notice the same problem on gnome-wayland? I found that in my case the issue is libinput (used by wayland instead of synaptics driver).

[etherealvisage]

Just wanted to comment that I have this as well, and it persists across orbment and sway, so it's probably as @mikkeloscar mentioned, in wlc. For me the cursor is more like 15 FPS, so it's very noticable. It's significantly slower when a window is open + being displayed.

[Chrysostomus]

I can reproduce it. I use libinput also in x, so it is probably not libinput issue.

[ghost]

I can also reproduce it. When no applications are opened, the mouse feels quite smooth, but once I open Amy applications such as URxvt (terminal) or Chromium (browser) the mouse starts lagging/stuttering.

[ddevault]

Guys, we don't another "I can reproduce this". Clearly it's a legitimate problem. What this needs is someone to investigate the problem, not someone to say they have it too.

[Drakulix]

I have noticed sway and other wlc-based compositors getting quite laggy in general when the system is under a lot pressure. This includes switching workspaces and similar.

My guess, would be that this happens, because the cursor is rendered via wlc in software and is not a hardware cursor like in GNOME for example. That means if sway is not scheduled regularly the cursor will not be drawn often enough.

As a first try to confirm this the priority of the sway task could be increased. But I doubt this will completely fix this issue.

[ghost]

I have used sway -d 2> ~/sway.logto debug this, the only error I have recieved was this one, which is likely unrelated:

02/12/17 18:08:44 - [main.c:44] [wlc] Failed to open X11 display

@andya9 When running GNOME on Wayland, I experince no mouse lags at all. Nouveau reports some issue while booting (dmesg) which I have reported on the Arch Linux forums here, yet I'm unsure whether they are related.

[WhyNotHugo]

@Drakulix So, is there any specific reason why sway uses a software cursor, rather than a hardware cursor?

[Drakulix]

@Drakulix So, is there any specific reason why sway uses a software cursor, rather than a hardware cursor?

Because wlc implements it that way. And I guess wlc does that because it is likely easier to implement.
Please don't blindy assume I am right or that a software cursor is inherently bad. It just provides some challenges that fit the symptoms discussed here.
As @SirCmpwn already pointed out this requires some more debugging, I just wanted to share some thoughts on the subject.

[stsquad]

I'm seeing similar symptoms (laggy cursor over some windows). It seems to be time specific, apps become laggy after time and killing them and restarting is fine. When I tried to move a window from my secondary to primary display it left corruption on the secondary display despite me switching to another workspace. However the corruption went away when I killed the lagged application.

Could this be GPU resource related? Is there anyway to see how much of the GPUs resources are tied up with each applications rendering buffers?

[stsquad]

It certainly seems to be GPU related: intel_gpu_tools says I am running ~7% render busy on a static terminal. Around 10-15% on this Chrome window I'm typing in and a steady 60-65% while the mouse is over a "laggy" window. It peeks another 10% up when I use the mouse.

Looking at htop I can see a slight uptick in cpu usage the laggy process on htop but sway goes from an idling sub 1% to 35% just by having the laggy window visible.

[etherealvisage]

Agree it seems GPU related in some way at least. On a X1650 Pro (GPU from 2006-era) I get barely 10FPS when moving a cursor across a terminal. RX 470 gives solid ~30FPS on the same window on the same computer with only the GPUs changed.

[stsquad]

I did run perf on sway to see if that pointed to anything. However even with the debug build I can't get decent backtraces. I see a lot of __memcpy_sse2_unaligned but I guess everything involves some sort of memcpy :-/

[cbuschardt]

You hit the nail on the head. There shouldn't be any large memory copies on the CPU in a window compositor. This should be done through EGL.

The problem is very pronounced on a 4k laptop. I see one core running at 70% load.

[ddevault]

Really this issue is a wlc issue, not a sway one. wlroots is going to replace wlc in the eventual future, and it's going to use a hardware cursor.

[teiesti]

According to this conversation, wlc has found and fixed the issue. The problem ~is~ was coming from a float-to-int typecast that was rounding small changes away. (Therefore you're only noticing the issue when moving the mouse very slow.)

Unfortunately, the typecast was in the API. So there is work to be done: wlc has decided to leave the old API for backward compatibility but there is a new one that should (hopefully) work as expected.

Could someone who knows sway's codebase have a look?

[ddevault]

Yeah, this is fixed as of 0.14-rc5.

[teiesti]

You're right! I've found the pull request just seconds ago... :+1:

[soulofmischief]

I am experiencing this bug on Fedora 29, using the latest available sway version 0.15.2-1, when running sway inside of a VM on a fresh image with just sway installed.

Brand new to sway so I'm not sure how to begin debugging this.

If using a hardware cursor is fixed in wlroots then w/e, I'll just tough it out.

[ascent12]

@soulofmischief Using software cursors comes with a noticeable input lag.
I'd highly recommend you upgrade to the sway 1.0-beta with wlroots; 0.15 is not supported any more.

[soulofmischief]

Fedora is still using 0.15. If 0.15 isn't supported anymore then the rpm maintainer needs to know because they're probably waiting for the next stable version.

[stsquad]

Certainly since upgrading to 1.0 on my #gentoo box I haven't noticed any cursor laginess.

[RyanDwyer]

Fedora is still using 0.15. If 0.15 isn't supported anymore then the rpm maintainer needs to know because they're probably waiting for the next stable version.

0.15 is the latest stable but isn't receiving patches from the sway project. This is because the 1.0 beta is better than 0.15 in pretty much every way but is still too new to officially call it stable.

[soulofmischief]

I see. Well thanks for all the hard work, I look forward to trying out sway when 1.0 arrives.