Window redraw lag when dragging windows

[wrouesnel]

Cinnamon 2.0.2 and all earlier versions I've used seem to do an excessive amount of processing when click-dragging windows.

This manifests as a slight, but noticeable stutter when sliding the window around, which makes the desktop experience seem laggy - it's extremely noticeable when I boot from Cinnamon into Windows 7, where windows slide around smoothly.

If I monitor the cinnamon process with top, I can see the CPU usage while not dragging, but doing something like playing a YouTube video sits at around 5-10%. The moment I start dragging a window (a Chrome window full of text) - cpu usage jumps to about 30%.

[jaszhix]

A good workaround is to add CLUTTER_VBLANK=none to /etc/environment and enable force composition pipeline on all monitors in nvidia-settings under Display Configuration -> Advanced. This moves vsync handling from the compositor to the driver, and helps on amdgpu as well with TearFree enabled in the xorg configuration.

[mikebutash]

Thanks for that, I set in my /etc/environment, but I've not found a need to try the hardware-rendered version, as it only seems to invite drama and chaos. I'm pretty happy with the software-rendered version so far, some drawing delays in cairo-dock and some other apps, but not terribly so like the hardware version that poops on itself.

[mikebutash]

Interesting, even in software mode now, I'm developing the same lag, but at a much slower rate than with full gpu rendering. Feels like some sort of resource leak, but if not direct rendering against the gpu, I'll presume some bug in resource management within the desktop.

What is useful feedback, logs, debugs, etc to help fix this? I see nothing abnormal anywhere, other than the desktop freaking out at random/common intervals.

[mikebutash]

Also to clarify, I think a lot of this has to do with the high-resolutions I use this at. My desktop runs at 11520x2160 (3x 4k displays), which taxes any desktop I find that even tries gpu acceleration. I don't think anyone factors that sort of thing, but with 4k, 5k, and now 8k coming on, the struggle is real. This is why compositing seems to break under any desktop, including unity, kde, cinnamon, or even mate/marco with direct rendering against gpu at this scale.

It's something to note to the develpers, the resolution scale to composite render properly has been an issue since ~2010 when I would run 6x 1080p displays under linux with the advent of compositing.

[mikebutash]

So I'm back again to check in on this, after experiencing 5 second delays in window redraw under software compositing most recently after around 80 days of uptime, I upgraded again to see what was new and hopefully improved. Long story short: not so much.

Now at 4.0.7 core cinnamon packages, and launching with software rendering as prior was abysmal with horrible flickering and weird refresh issues around parts of the windows (ie. the minimize/exit buttons particularly). Trying hardware mode, it works without that, but almost immediately I began to get a refresh lag within a few days of use that is growing steadily as it did prior with hardware mode that drove me to use software. Software seems a basketcase in 4.0 so far, but hardware rendering still has this issue going back years.

What might it take to actually fix this? Resolutions aren't getting smaller in displays, and these compositors can't seem to handle anything beyond old HD resolutions still.

[jaszhix]

@mikebutash Software rendering mode was never intended to be used while the graphics driver is loaded. It's for VGA mode.

There is an assortment of PRs open for 4.2. If you feel comfortable testing them you can checkout my PR branches on the Muffin repo. The other option would be disabling vsync in Settings -> General and enabling force composition pipeline in nvidia-settings. There is nothing else that can be done to fix this for the 4.0.x series.

Edit: Also see this wiki page.

[mikebutash]

@jaszhix, agreed it's not mean to be a solution, but says something that it works better than the preferred hardware method, particularly over time. Not so much on newer 4.0 though, another regression with the flickering and extreme lag, and immediately the incremental lag has begun again on hardware. The fact it grows worse with time shows code instability, which it's done since early 3.x, and likely into your 4.2 still, so I doubt it matters what version I'm actually on.

I'd done both vsync and forced pipeline per recommendation prior, but did notice checking right now that the force full composition pipeline was disabled again in nvidia-settings, so reenabling and will see how that fares. I already still see an occasional lag after enabling it on all displays, though remains to see how if it gets steadily worse as it tends to.

If all the DE's are so hell-bent on compositing, it would be nice if they'd ensure stability at scale in resolution, as they all mostly suffer the same issues at large resolutions. Cinnamon on mine acts like a memory leak, prior to reboot/upgrade after 90 days or so, I would see cinnamon-desktop commonly using 80-90% of a cpu in process a top-talker in htop (didn't seem to thread well at core as I have 39 other threads it could use), and used a lot of memory, some 20-30gb (something to be said having 128gb in this system). There needs to be a way to test this at scale, and some sort of valgrid-like stress testing it would seem. After 90 days or so of use here, cinnamon is always ready to pop, and that's in Software render. It'll usually die within a week in hardware. KDE suffers much the same.

Most folks aren't running 11200x2160 resolution worth of displays commonly, but that's only 3x 4k displays, which are becoming more common and cheaper every day, or adjust itself accordingly. At some point the composting needs to account for resolutions like this, and greater, with long-term stability, or figure out a method of compromise that will better suit the masses. Rather have stable redraws on my windows than wobble/transparency to them over time. If I knew what was destabilizing my system, I'd happily disable it.

[jaszhix]

What is the version of your Nvidia driver? If you're using 390 or 396, use 415.25 on the Ubuntu PPA.

The combined resolution of my monitors is 8560x1440, and I'm not seeing any slow-down with Cinnamon over time on my PR branches currently, in the few periods I'm not restarting Cinnamon for development.

Force composition pipeline does add some latency. I generally don't recommend its use, and if you're seeing issues with Cinnamon's vsync, make sure "Allow flipping" is enabled in nvidia-settings, and "Sync to vblank" is disabled. Don't use any driver workarounds intended for 3.8 and older.

It's not clear to me what you consider lag - is it the cursor being out of sync with the window when dragging? Or general input latency of windows? Those things are affected by different parts of the compositor code. https://github.com/linuxmint/muffin/pull/397 improves both, and https://github.com/linuxmint/muffin/pull/392 improves the latter - which I would have liked to get into 4.0, but it needs more testing.

another regression with the flickering and extreme lag

Let's keep these issues separate, there are already a couple issues regarding flickering, and I haven't observed it being any worse on 4.0. Of course it needs to be fixed, but it is difficult to fix something that can't be reproduced reliably.

[mikebutash]

So as of my last upgrade, I'm on nvidia 415.25-4, so within your expectations.

I set allow flipping on (not done before), sync to vblank disabled (done usually), and the force full compositing pipeline on each display (reset this time checking).

Lag, is like everything I do. If I click between windows, redraw results in some lag, in the screen stopping for a few seconds at a time as frozen in place. I've been playing Overlord on steam recently where it does this, quite annoyingly during battle. I've learned to notice and preempt when it occurs. Desktop use results in this stall as well, typing this results in various lags/stutters of clicking between windows and during typing. Everything stops for a second or two during typing or any mouse or keyboard activity randomly.

Dragging things tends to exacerbate the issue, most UI things tend to anger and lag the desktop, stalling things visually for a second or two. Fast forward 90 days, this results in a 5 second stall in everything you do when it decides to hit, which is every few minutes, and sometimes less.

[mikebutash]

Regarding flickering, I've noticed this happening across all displays, randomly certain areas, not always the same, but like some sort of ghost area of past that will start flickering for seconds at a time, and go away. This is across all 3 displays in 4k, some small subset of one at a time.

This is another artifact of rendering in software it seems, but weird when it does. I've not seen this under hardware rendering, but did plenty with software the last 90 days or so using that. Bad enough under hardware without weirder things in software.

[jaszhix]

I set allow flipping on (not done before), sync to vblank disabled (done usually), and the force full compositing pipeline on each display (reset this time checking).

Basically what I was suggesting was re-enabling muffin's vsync in Settings -> General, and disabling force full composition pipeline. You will experience the most lag if both are enabled.

The flickering is definitely worse on software rendering, and when using certain Clutter env variables that are used when it's on. I have not seen this occur when booting with the nomodeset parameter, but flickering will occur if the Nvidia driver is loaded while Cinnamon uses software rendering. See #7985.

The "stalling" behavior sounds like the thread is getting blocked intermittently, are you using any third party applets/desklets/extensions? Check with gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions.

[mikebutash]

I gotcha, not sure how much of a pain it is under arch to try to be honest, or normally I'm down. I tend to run with their releases, upgrading, and praying a little that the problem just goes away. Not across major revisions now though, 3.x to 4.0 now. I try not to deviate much, I make a living off this system, including various vpns, virtual machines, and various other integration points I do with it.

I don't get the flickering under hardware, though it does get the random lag almost immediately booting into that. It's getting worse already I can tell.

[mikebutash]

Yeah, I had to stop using Cinnamon again, the window redraw lags were killing me after a few days only, getting up to 5 second lags in any window refreshing that I was actively using. Trying to game with this is impossible. Normally I'd revert back to software rendering where it takes usually months to get to the same long delays in updates, but software rendering now in 4.0 is entirely unusable.

On an up beat, KDE/Kwin is still a basketcase as well, almost the same issue, but I'll simply never get the window to refresh at all, having to minimize and reselect the window to get to redraw with any changes.

Why is this really so hard for compositors in different DE's to get?

[mikebutash]

I did check on the 3rd party extensions, and no, all I had was cinnamon extensions, and mostly default ones. I usually overlayed cairo-dock and used it for custom things.

I've spent a good amount of time watching htop, iotop, nvtop, and powertop, and others trying to find why this occurs, but I never see anything in particular show up as a resource pig in any way, outside of cinnamon-desktop itself, and xorg over time.

This of course is where it always gets fuzzy, how much is xorg, nvidia drivers, or cinnamon misbehaving? I don't know of any good ways of debugging those internally. I'm open ears if you know of a good way of watching the internals of those for issues, particularly cinnamon itself since it definitely becomes a resource hog over time.

The applications are doing their thing, only the window isn't getting redrawn during those "lag" moments, so I agree something is getting blocked, but I can't figure out what it is.

I did have to switch to kde as the lag was causing much grief here to use finally, but kde is looking like no champ, so willing to try cinnamon again. Mint is almost too simple, I can't much stand gnome3, particularly ubuntu's dysfunctional version of it, so I keep coming back to cinnamon despite the issues. I'd really love to help fix them if possible as obviously I'm not the only one by this thread.

I am a bit curious what happened to the other folks seeing this...

[jaszhix]

Why is this really so hard for compositors in different DE's to get?

Optimizing compositing is hard to do, and requires a lot of trial and error. It's simply not an easy thing to work on.

all I had was cinnamon extensions, and mostly default ones. I usually overlayed cairo-dock and used it for custom things.

Mostly? Which extensions are in use? That is an important detail. We need information that can help reproduce the issue, not wall of text rants about compositing. Thanks!

[mikebutash]

There was one desklet that seemed enabled, bbcwx, a weather applet, but I didn't see any sign of it present or running prior.

[user@host ~]$ gsettings get org.cinnamon enabled-applets ['panel1:left:0:menu@cinnamon.org:0', 'panel1:left:1:show-desktop@cinnamon.org:1', 'panel1:left:2:panel-launchers@cinnamon.org:2', 'panel1:left:3:window-list@cinnamon.org:3', 'panel1:right:0:notifications@cinnamon.org:4', 'panel1:right:1:user@cinnamon.org:5', 'panel1:right:2:removable-drives@cinnamon.org:6', 'panel1:right:3:keyboard@cinnamon.org:7', 'panel1:right:4:bluetooth@cinnamon.org:8', 'panel1:right:5:network@cinnamon.org:9', 'panel1:right:6:sound@cinnamon.org:10', 'panel1:right:7:power@cinnamon.org:11', 'panel1:right:8:systray@cinnamon.org:12', 'panel1:right:9:calendar@cinnamon.org:13', 'panel1:right:10:windows-quick-list@cinnamon.org:14'] [user@host ~]$ gsettings get org.cinnamon enabled-desklets ['bbcwx@oak-wood.co.uk:1:50:50'] [user@host ~]$ gsettings get org.cinnamon enabled-extensions@as []

I do realize that dealing with the compositing is complex work, so I don't mean to downplay the effort, and I certainly do deep down appreciate them, but compositing is in every DE I use the weakest link in everything under linux. Even in Windoze, Aero can be a basketcase for compositing I've found in my limited use of it out of box on a dell laptop. Amazing how many unique efforts seem to get this wrong, so I just question why this is so necessary when seemingly impossible to accomplish well enough. Seems there should be a better way.

[jaszhix]

Ah ok, so if bbcwx is enabled but not rendering, then it may be misbehaving. There's also a few PRs I've opened intended for 4.0.x that could be affecting performance, like #8180. I'm not sure when that one is getting merged but everyone should be using it, or switch to GWL.

I understand the frustration - it's why I started learning C so I could improve muffin, but there's not much I can do except open PRs (which I've been doing). Graphics on Linux in general have been behind for a long time, and just recently started catching up after some big changes (e.g., proton). There's a lot of work to do, and my goal is to make muffin as responsive as DWM in Windows 10.

[mikebutash]

I don't even quite remember enabling it, so must have been something random and forgotten about. I'll remove it, if I can figure out how.

I've been using linux since 2006 full-time, and remember before/after compositing, and life was much simpler before. I dealt with Ubuntu and Compiz problems for years when that started, it drove me to KDE, later to Mate/Cinnamon, and now back and forth lately which ever one sucks less.

So far going from 3.x to 4.0 was the worst with Cinnamon, but kwin, compiz, mutter, they all seem to suffer from some inherent resource leakage that just gets worse over time. Since they all do it, I often suspect it's a lower-level component, like xorg or nvidia driver that are causing the destabilization among all DE's, but really no way to tell. Thus I start with the DE, but I do watch also various *top's to try to figure out what is causing these graphic delays, so far to no avail.

I tend to follow arch normal pacman upgrades to try pulling in updates outside that cleanly, not sure how to go about trying the next muffin releases in arch or I would.

[sgtcoder]

I also have this issue. See screenshot for my specs. I even have 128GB of RAM: https://gyazo.com/1f0443df15097949a2314bebba6d12db

[melroy89]

Solved my moving to XFCE >< (so its not solved in Cinnamon)

@sgtcoder Where the h*K you do use 128GB ram for? Maybe its time that you move to XFCE for sure in your case.. haha

[sgtcoder]

@danger89 yah I love XFCE, I just switched over to Cinnamon after years of XFCE. I liked Cinnamon for the modern desktop and their integrations. It sucks that it requires OpenGL to run.

Well my board supported it, so I put it in XD. But that way, for work, I never run out. Basically unlimited. But it still runs slow in Cinnamon!!

[melroy89]

@sgtcoder Welcome at where the bottleneck is. Its properly not due to your memory size, still it could be the memory speed/latency and whatever not. And the rest of the PC (disks/motherboard/hm.. etc.).

Nevertheless, likely its not related to your specs at all as you can see in the above section. There is some bug in either the videodrivers, Xorg or something in that area.

[sgtcoder]

@danger89 it's definitely an issue with Cinnamon. I read the v4 might be better, but it's not stable enough for Debian yet.

[zunjack]

Luke Lafreniere just shamed Cinnamon on Linus Tech Tips for taking so long to fix this.

[warlon]

This part of the video shows the issue in action: https://youtu.be/TtsglXhbxno?t=1294

[uzarnom]

Hi All, so I recently installed mint. I have been having windows stuttering issues as well. I managed to resolve it.

Keeping in mind, I have an Nvidia card, with 2 monitors running at different refresh rates. (60Hz and 144Hz).

I following this guide: https://forums.linuxmint.com/viewtopic.php?t=367756

Steps

re-writing the part of the guide that worked for me

1. open display application, ensure the refresh rate is correct for my monitors (60Hz and 144Hz)
2. go to terminal and enter nvidia-settings
3. in the nvidia settings GUI go --->X Screen 0 > OpenGL Settings
4. turn off "Allow Flipping"
5. and that was it, the guide says I'll need to redo it on every restart but I didn't need to

Inix -Fxxxrz

Expand my systems details

``` System: Kernel: 5.4.0-100-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 Desktop: Cinnamon 5.2.7 wm: muffin 5.2.0 dm: LightDM 1.30.0 Distro: Linux Mint 20.3 Una base: Ubuntu 20.04 focal Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX B450-I GAMING v: Rev 1.xx serial: BIOS: American Megatrends v: 4007 date: 12/08/2020 CPU: Topology: 8-Core model: AMD Ryzen 7 2700X bits: 64 type: MT MCP arch: Zen+ rev: 2 L2 cache: 4096 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 118171 Speed: 2184 MHz min/max: 2200/3700 MHz boost: enabled Core speeds (MHz): 1: 1883 2: 1950 3: 2058 4: 1984 5: 2194 6: 2190 7: 2189 8: 2146 9: 2190 10: 2048 11: 2194 12: 2194 13: 2186 14: 2170 15: 2190 16: 2029 Graphics: Device-1: NVIDIA TU106 [GeForce RTX 2060 Rev. A] vendor: Gigabyte driver: nvidia v: 510.47.03 bus ID: 06:00.0 chip ID: 10de:1f08 Display: x11 server: X.Org 1.20.13 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa resolution: 1920x1080~60Hz OpenGL: renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2 v: 4.6.0 NVIDIA 510.47.03 direct render: Yes Audio: Device-1: NVIDIA TU106 High Definition Audio vendor: Gigabyte driver: snd_hda_intel v: kernel bus ID: 06:00.1 chip ID: 10de:10f9 Device-2: AMD Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 09:00.3 chip ID: 1022:1457 Device-3: Plantronics HD1 type: USB driver: plantronics,snd-usb-audio,usbhid bus ID: 5-1:2 chip ID: 047f:c03b Sound Server: ALSA v: k5.4.0-100-generic Network: Device-1: Intel I211 Gigabit Network vendor: ASUSTeK driver: igb v: 5.6.0-k port: d000 bus ID: 03:00.0 chip ID: 8086:1539 IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: Device-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter vendor: ASUSTeK driver: rtw_pci v: N/A port: c000 bus ID: 04:00.0 chip ID: 10ec:b822 IF: wlp4s0 state: down mac: Drives: Local Storage: total: 3.42 TiB used: 26.04 GiB (0.7%) ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 1TB size: 931.51 GiB speed: 31.6 Gb/s lanes: 4 serial: rev: 3B2QEXM7 scheme: MBR ID-2: /dev/sda vendor: Samsung model: SSD 860 QVO 1TB size: 931.51 GiB speed: 6.0 Gb/s serial: rev: 1B6Q scheme: MBR ID-3: /dev/sdb vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB speed: 6.0 Gb/s serial: rev: 3B6Q scheme: MBR ID-4: /dev/sdc vendor: SK Hynix model: HFS256G39MND-3310A size: 238.47 GiB speed: 6.0 Gb/s serial: rev: 2P00 scheme: MBR ID-5: /dev/sdd type: USB vendor: Toshiba model: External USB 3.0 size: 931.51 GiB serial: rev: 5438 scheme: MBR Partition: ID-1: / size: 915.40 GiB used: 15.39 GiB (1.7%) fs: ext4 dev: /dev/nvme0n1p5 Sensors: System Temperatures: cpu: 45.5 C mobo: N/A gpu: nvidia temp: 50 C Fan Speeds (RPM): N/A gpu: nvidia fan: 36% Repos: No active apt repos in: /etc/apt/sources.list Active apt repos in: /etc/apt/sources.list.d/1password.list 1: deb [arch=amd64 signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] https://downloads.1password.com/linux/debian/amd64 stable main Active apt repos in: /etc/apt/sources.list.d/additional-repositories.list 1: deb https://dl.winehq.org/wine-builds/ubuntu/ focal main Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 1: deb http://packages.linuxmint.com una main upstream import backport #id:linuxmint_main 2: deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse 3: deb http://archive.ubuntu.com/ubuntu focal-updates main restricted universe multiverse 4: deb http://archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse 5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse 6: deb http://archive.canonical.com/ubuntu/ focal partner Info: Processes: 401 Uptime: 29m Memory: 15.62 GiB used: 4.48 GiB (28.7%) Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Shell: bash v: 5.0.17 running in: gnome-terminal inxi: 3.0.38 ```

[lukas-the-wizard]

Luke Lafreniere just shamed Cinnamon on Linus Tech Tips for taking so long to fix this.

Linux mint is a buggy mess and noone in the dev team cares. The proof is that this issue is almost 10 years open

TLDR Dont use Cinnamon for anything

[maxwell-kalin]

I was introduced to linux with mint. Its sad to see this.

[melroy89]

Linux mint is a buggy mess and noone in the dev team cares. The proof is that this issue is almost 10 years open

I really think that the Linux Mint dev team is doing a good job like @mtwebster is really doing it's best over here. So fist of all, all the ❤️ to Linux Mint. It's hard for just a few devs that are actively contributing to this project, making a good open-source and free product for us all. Cinnamon is mainly maintained now by mtwebster and that's about it.

If you compare that to the big tech companies like Microsoft. Microsoft says 1.3 million backend programmers worked on Windows 10. 800k designers, and 2 billion testers. So I think the world is not fair.

Creating over 1k issues on GitHub is easier than solving them and fixing all the C code.

[a73s]

can confirm this is still a problem. only problem i have ever had with mint, its tolerable though. PRO TIP: it doesnt happen if the youtube video is fullscreen.

[melroy89]

We really need Wayland sooner than later

[a73s]

This is solved for me with mint 21. must be the window manager/compositor update

[akaIDIOT]

This problem started with Mint 21.1 (cinnamon 5.6.2+vera / muffin 5.6.2+vera) for me. Tried @uzarnom's solution of disabling flipping in the OpenGL settings to no avail. Like @a73s, though, it does seem to go away for full screen windows, as it's very noticeable when a video is playing in Firefox, for example. Dragging things around, I can see 'global the refresh rate isn't effected as the mouse cursor twirls about happily enough, it's just the window being dragged that's slugging behind, as well as its contents.

Recently upgrade to 21.1 from a fairly fresh 21. Before the upgrade, this was not an issue, everything seemed smooth enough. Running an nvidia 2070 super into 165Hz 3440×1440 and a 60Hz 5260×1440, both over their own displayport cables. Happy to provide other things that might be help in diagnosing this.

edit: fooling around with this, it's noticeable that the issue on the main screen (the big one) gets resolved by putting whatever's on the second screen in full screen so no parts of the desktop env are visible. Having no windows open over there makes no difference, still stuttery. Oddly enough, there's no need to put things full screen on the main one…

[Scramblejams]

FWIW, I had this issue as long as I had multiple monitors and was using an Nvidia card to drive them. On my last upgrade I switched to a recent AMD GPU, using the open source amdgpu driver, and the problem went away. (Well, still not as smooth as when I'm trying Wayland, but that's a separate issue.)

[akaIDIOT]

I recently noticed that my symptoms include way higher than expected CPU usage, on a single core. Tried some timing things, seems to not be hung up in system calls, but haven't been able to figure where that cpu time (that goes up when I drag a stuttery window around) goes yet.

[maxwell-kalin]

its pathetic that this issue is after 10 Years still a thing.

Never Mint again...

[seyfer]

I have this on latest Cinnamon and ubuntu 23.04

[akaIDIOT]

FWIW: this problem completely went away for me by swapping out my nvidia card for an AMD one (switched purely because of this issue). Never really managed to find out what was causing the higher CPU usage, but somewhere in the stack, changing from nvidia to AMD fixed both the higher CPU usage and the resulting lagginess.

[claudiux]

nVidia code is private code.

[melroy89]

The issue is closed. Does that mean the window redraw lag is gone?

[akaIDIOT]

That was surely not my intention with the comment a couple hours ago... It's an observed difference, no statement claiming nVidia's code was the culprit here. Considering the whole things is noticeably different when something is in full screen mode, there's at least some weirdness going on somewhere, maybe not in nVidia's private code.

Just meant I can't really test anything anymore, as I can no longer reproduce it on different hardware...

[a73s]

This should not have been closed, it cannot be assumed that it's nvidia's code causing the issue. If it was on nvidia's end wouldn't you see the same issue with other desktops?

[andrewfraley]

It's been over nine years since I first commented on this, but I first observed this same behavior on Intel graphics. I don't know if it's still a problem for Intel graphics, however.

[claudiux]

I haven't encountered this problem in years with Intel or AMD graphics cards.

[811Alex]

I'd like to echo @a73s's sentiment. On the exact same system Cinnamon had this issue on (multi-monitor desktop, Nvidia GPU, Intel CPU, plenty of resources), I've tried XFCE and KDE Plasma, both looked as smooth as it gets. I haven't experienced this problem on any other DE.

Make no mistake, this is a Cinnamon issue.

[seyfer]

this is totally cinnamon with a GPU rendering issue I did switch to the CPU rendering session, and everything ran smoothly.

[darkguset]

I have this on latest Cinnamon and ubuntu 23.04

Same here on Mint 21.2 with Kernel 6.2.0.39 - NVIDIA 3080Ti, dual monitors (main screen on DP0, secondary on HDMI0) - when both monitors are active moving windows on the main screen are jerky even though the mouse pointer is smooth and main monitor also reports 144Hz (secondary is at 60Hz). When deactivating the secondary monitor the jerkiness goes away. I tried disabling the flipping method in OpenGL to no avail.

I think it might have something to do with the fact that the two monitors are running at different refresh rates. I changed both to 60Hz and the jerkiness seemed a bit less. It might be a placebo effect though, I can't be sure.

[akaIDIOT]

What @darkguset mentions sounds identical to what my situation was. What was interesting to me, and potentially useful in helping others / developers to debug this, is that the CPU usage spiked while dragging the stuttery windows. I couldn't find a decent way of logging or profiling what libraries or functions cause the usage spikes.

Would cinnamon developers be able to help with setting things up to uncover that kind of information? Hoping @darkguset would be willing and able to help, I've changed my hardware and can't currently reproduce the issue I had...