Variable drawing performance

[ItsLemmy]

Please fill out the following:

• Scroll Version:

  • commit d5c08ae

• Description:

  • Really liking the project so far!
  • But I'm having major performance issues when using Scroll on a multi monitor setup.
  • My workstation has 3 monitors, as soon as I enable more than one monitor the drawing performances tank heavily. When using our shell (Noctalia shell) every opening of a panel or during wallpaper change I can see a clear micro-freeze (probably 50 to 100ms) that make all animations choppy / buggy.
  • I tried disabling monitors and that fixes the problem but ofc not practical for my use case
  • It seems there is a bunch of unnecessary redrawing happening when using multiple monitors, for example it seems a single screen damage triggers a full redraw of all screens. But take this with a grain of salt I did not dig too deep in the code yet.
  • As a Noctalia-shell's developer, I test our shell on many compositors (Niri, Hyprland, Sway, Scroll, Labwc, Mango, River) and Scroll is the only one to have a hard time with our animations.

Let me know if I can help. Thanks.

[dawsers]

Thank you.

When you talk about bad performance, does it happen when Noctalia shell is not enabled? I use two monitors and have several users with three that haven't complained about performance issues.

I see Noctalia uses quickshell, and quickshell creates its own animations, bypassing scroll's animation system. My previous efforts to add scroll specific stuff to quickshell have been ignored, so I don't know if I can do anything about this. I spent quite a bit of time on that PR and writing scroll-specific modules I was planning to distribute as a more modern alternative to scrollbar, but that all ended up in limbo.

If that is not the case, and you always see bad performance, even with quickshell disabled, please let me know too. If the problem is only with quickshell applications using animations, know quickshell uses Qt animations, which have their own render loop, scene graph etc. quickshell has removed its use of the simple animation driver (QSG_USE_SIMPLE_ANIMATION_DRIVER=1). Maybe you can try enabling that and see how it goes.

From their source code:

	// While the simple animation driver can lead to better animations in some cases,
	// it also can cause excessive repainting at excessively high framerates which can
	// lead to noticeable amounts of gpu usage, including overheating on some systems.
	// This gets worse the more windows are open, as repaints trigger on all of them for
	// some reason. See QTBUG-126099 for details.

	// if (!qEnvironmentVariableIsSet("QSG_USE_SIMPLE_ANIMATION_DRIVER")) {
	// 	qputenv("QSG_USE_SIMPLE_ANIMATION_DRIVER", "1");
	// }

And from the KDE Arch Wiki:

Setting the environment variable QSG_USE_SIMPLE_ANIMATION_DRIVER for KWIN
 reduces jerking in some Quick Scene Graphics based effects. For this purpose, it is
 sufficient to create a drop-in for the service running KWIN:

This bad performance, does it work better in sway, or is it scroll specific?

Edit: I forgot to say Qt 6.11 seems to have improved their scene graph and animation system. I haven't had a look at it yet, but you may also try recompiling quickshell and testing the different possibilities with respect to "animation drivers". If you confirm your issues only happen with quickshell enabled, I will have a look at this too.

[ItsLemmy]

Hey!

About Quickshell, we forked Quickshell into noctalia-qs for our own use case as we needed more flexibility (ex: support for compositor specific features + faster release schedule)
I would gladly merge PRs or even write scroll specifc stuff if needed!

About the performance degradation, this is not specific to Quickshell/Qt. I used Noctalia for eference as I'm very familiar with it and I could tell something was off immediately. I also see that lag happening on simple operations like opening a terminal, sometimes it's super smooth with a 250ms animation (as expected) sometimes it feels like it's 15fps.

This works perfectly fine on Sway and other wlroots based window managers.

After some more digging this morning, I realise the issue is not dependent on the monitor counts. It's just drifting overtime and get laggy for me. So my initial assumption was wrong. I use 3 screens with all different refresh rate.

That being said, I believe I just found the main cause, I'll open a PR soon. The animation system uses a fixed 16ms timer disconnected from the display's vblank timing. Over time the timer phase drifts relative to the actual refresh rate, causing periodic frame drops. The fix is to drive animation frames from the output's own frame callbacks instead.

[dawsers]

Thank you, I will gladly look at the PR!

wlroots is quite good with damage and avoiding unnecessary drawing. So, when I hacked the animation system on top of sway, I added the timer you mention, to force animations (16ms by default, but can be modified), and there is also frame generation for each output repaint timer handler. So if the output requests a repaint, it also triggers an animation. The problem may lie there, in some cases I may need to discard one or the other.

[dawsers]

I also forgot to mention you should probably use the Vulkan renderer. I use it daily and will become the default soon. It is more efficient and multi-threaded.

Add this to your ~/.bash_profile or wherever you set your environment variables

export WLR_RENDERER=vulkan

or start scroll with

WLR_RENDERER=vulkan scroll

[ItsLemmy]

Oh yeah totally forgot about that, I just enabled it and running with it now. Thx

[ItsLemmy]

Another small thing I noticed. is cursor_shake_magnify true supposed to be smooth ?
For me it's very laggy, in the attached video I'm just doing circles with the mouse and as you can see it keeps freezing at random spots.

recording_20260327_143639.mp4

[dawsers]

Another small thing I noticed. is cursor_shake_magnify true supposed to be smooth ? For me it's very laggy, in the attached video I'm just doing circles with the mouse and as you can see it keeps freezing at random spots.

This was al old request, but never got any feedback, and I don't use it. It is based on a heuristic that worked well on my computer :-)

// Shake cursor detection
static const uint32_t SHAKE_MSEC = 500;
static const uint32_t SHAKE_MIN_PIX = 200;
static const int SHAKE_MIN_SEGMENTS = 4;
static const double SHAKE_FACTOR = 2.5;
static const double M_PI = 3.14159265358979323846;

static bool cursor_detect_shake(struct sway_cursor *cursor, uint32_t time_msec) {
	struct Position {
		double x, y;
		uint32_t time;
	};
	static list_t *history = NULL;
	if (history == NULL) {
		history = create_list();
	}
	bool reused = false;
	struct Position p0;
	p0.x = cursor->cursor->x;
	p0.y = cursor->cursor->y;
	if (history->length > 0) {
		struct Position *p1 = history->items[history->length - 1];
		const double len_p1x = p0.x - p1->x;
		const double len_p1y = p0.y - p1->y;
		if (history->length > 1) {
			struct Position *p2 = history->items[history->length - 2];
			const double len_p2x = p0.x - p2->x;
			const double len_p2y = p0.y - p2->y;
			if (len_p1x * len_p2x >= -0.5 && len_p1y * len_p2y >= -0.5) {
				p1->x = p0.x;
				p1->y = p0.y;
				p1->time = time_msec;
				reused = true;
			}
		}
	}
	if (!reused) {
		struct Position *new_pos = malloc(sizeof(struct Position));
		*new_pos = p0;
		new_pos->time = time_msec;
		list_add(history, new_pos);
	}
	for (int i = 0; i < history->length; ++i) {
		struct Position *pos = history->items[i];
		if (pos->time < time_msec - SHAKE_MSEC) {
			list_del(history, i);
			i--;
			free(pos);
		} else {
			break;
		}
	}
	if (history->length > SHAKE_MIN_SEGMENTS) {
		double length = 0.0, rotation = 0.0;
		for (int i = 2; i < history->length; ++i) {
			struct Position *p0 = history->items[i];
			struct Position *p1 = history->items[i - 1];
			struct Position *p2 = history->items[i - 2];
			double a2 = (p1->x - p2->x) * (p1->x - p2->x) + (p1->y - p2->y) * (p1->y - p2->y);
			double b2 = (p1->x - p0->x) * (p1->x - p0->x) + (p1->y - p0->y) * (p1->y - p0->y);
			double c2 = (p0->x - p2->x) * (p0->x - p2->x) + (p0->y - p2->y) * (p0->y - p2->y);
			length += sqrt(b2);
			if (a2 * b2 == 0.0) {
				continue;
			}
			rotation += M_PI - acos((a2 + b2 - c2) / (2.0 *  sqrt(a2 * b2)));
		}
		if (length > SHAKE_MIN_PIX && rotation > SHAKE_FACTOR * M_PI) {
			return true;
		}
	}
	return false;
}

I am sure I could improve it making those hard-coded values relative to screen size or mouse sensitivity or whatever, but
scroll has very few users, so QA is quite lacking some times, it is just basically me and whoever files an issue.

Edit: So to the point, it works relatively well on my computer, given it is a hack to dynamically change cursor theme.

[dawsers]

About Quickshell, we forked Quickshell into noctalia-qs for our own use case as we needed more flexibility (ex: support for compositor specific features + faster release schedule) I would gladly merge PRs or even write scroll specifc stuff if needed!

Thank you.I will ping them again next month, as I usually do, and if I don't get an answer, I will try with you guys. The problem with the fork is when I tried Noctalia, it had a conflict with the quickshell I had installed for my widget development, so I gave up. It is unfortunate having to fork, but I completely understand why you did it. My changes were mainly on the I3 socket protocol to add scroll-specific IPC stuff, like binding modes, marks, key bindings, trails, spaces, mode modifiers etc. I wrote some widgets to query/change mode modifiers etc. and the plan was to release them so people could create a more modern bar than scrollbar. Maybe I should try Noctalia and submit the PR there. It was not really for me, because I use my own bar, less features, but very light on CPU resources, C++ and with some very specific things I rely on.

[dawsers]

I merged your PR and submitted my changes to remove the timer in 350b03e. Please, let me know if you see any improvements in your setup. I use two big 4K 60 Hz monitors, so there is little I can test here.

[dawsers]

Hmm...something broke here

[ItsLemmy]

FWIW Our fork is 100% compatible with the original Quickshell, so you can run any project with it.
Ofc Quickshell is not for everyone, as Qt is ram hungry. I personaly run a very basic bar with the bare minimum.

[dawsers]

Hmm...something broke here

There was a bug introduced by the animate_root() optimization. The animation system had a animation->enabled flag to decide whether an animation had already finished or wasn't needed. It was computed during the animate_xxx() in transaction.c, by checking whether each node was still changing position or size. As the flag was global (for all the outputs in the animation), selectively running animate_output() only for one output as done in the optimization, was causing the flag to be updated incorrectly. Now there is a flag for each output and the optimization works again.

I introduced this fix in 362e6a4.

I think this should be ready for testing. Please, let me know if you see things working as you expect, or you still see performance issues. Thank you.

[ItsLemmy]

Yep I kept an eye on your commit from yesterday. I'll test that in a few and report back.