Cinnamon: Window redraw lag when dragging windows

I hate to say "me too", but..."Me too!" I'm running on a somewhat older box, with Cinnamon running on top of Ubuntu 13.04. Everything else seems OK, it's just window dragging that is an issue. And the "stutter" is noticable, after which the window just jumps to the next point. It seems to happen when dragging any window (chrome, uxterm). Let me know what other supporting info I can provide. I can't find anything interesting in my system logs.

I can confirm this, but i have a very poor graphics card...

I'm experiencing these same issues too. I'm running the latest Cinnamon from the nightly ppa on Ubuntu 13.10.

I run a multihead system on arch linux with cinnamon 2.0.2 currently (3x 1920x1080) i have tried both a 660 and my 7870. They both exibit the same behavior, extremly laggy windows when moving or sizing. Im using the opensource drivers atm. (Will try catalyst once they are updated to work)

On my system its almost unbearable.

---Update--- if I disable in Cinnamon Settings panel -> Window Tiling and Edge Flip -> Window Tiling and Snapping - the windows move again fast across the screen; I got this hint by moving around a window and I got the new HUD thing showing me the position that I could put that window; whenever HUD was showing up the lagg will start.

I can confirm the same behaviour on my laptop; using Manjaro Linux and Cinnamon 2.0.6
I have a dual-core P6100 CPU and an Intel HD 3000 graphics card.
I dind't have this issue before with 1.6 or 1.8.
I was looking for an option with Muffin to disable "window content" while moving but no luck so far, using Dconf editor.
It would be great if someone would provide an explanation why this is happening.
Keep up the good work ;)!

The delay on windows dragging is nothing compared to resizing windows (eg: gnome-terminal), it can take several seconds :-(

I confirm this bug with Intel core I5 and Intel graphic controller (2nd generation).

You can set the tile HUD threshold to 1 and it will essentially disable the HUD display while still keeping tiling enabled. Maybe in the next version a more direct way of disabling it can be added, along with a more robust set of graphics for animating the HUD.

I can confirm this bug on i7-2600K CPU and AMD R9 290 GPU(latest beta drivers). Particularly on my 120hz screen. Disabling tiling and snapping did not help.

What version of Cinnamon are you running? One cause of this was patched relatively recently.

https://github.com/linuxmint/muffin/commit/403d24edc854c6610ff46427b6cf2072fa62bfa5

I am running Cinnamon 2.0.14. Will try to install the latest.

Having the latest muffin is probably more important. If you're on muffin 2.0.4 you don't have the fix yet. If you run 2.0.5 it will have it.

(I'm not guaranteeing your particular issue is fixed, could be some other cause possibly, but it's worth checking)

I am experiencing something similar with Cinnamon 2.0.14 and Muffin 2.0.5 on Mint 16 with an i5-4440s with Intel HD 4600 graphics. When I drag Windows they cannot keep up with the mouse cursor. It's as if the windows are are attached to my cursor with a small rubber band.

Here's a video of what I'm experiencing. Is this normal behavior? http://youtu.be/KylzMTZpD7w

I can confirm this case is still valid for Cinnamon 2.2.14 and also Gnome Shell 3.12.2 on Debian Jessie.

I also get this and it's really distracting to be honest. Markedly less smooth than Unity etc, and indeed Windows...

Experiencing the same thing I complained about previously, but also with an NVidia GTX 760. The problem is definitely worse with multiple monitors.

I get this on Cinnamon 2.2.14, too, with an NVidia GT 630 with the proprietary driver version 340.24 (and two Monitors). When downgrading to driver version 304, the windows move fast again, but then I experience tearing.

On Sun 10 Aug 2014 04:04:47 AM EEST, Andres Manz wrote:

I get this on Cinnamon 2.2.14, too, with an NVidia GT 630 with the
proprietary driver version 340.24 (and two Monitors). When downgrading
to driver version 304, the windows move fast again, but then I
experience tearing.

Window drag lag disappears when the vsync is disabled via the
environment variables. AFAIK Nvidia driver 304 doesn't enable vsync by
default (unlike the newer ones), so it may explain why you have fast
dragging and tearing when you downgrade to it.

High CPU usage is prevalent regardless of vsync, though.

Can confirm that windows are a lot less laggy if I make no attempt to enable vsync (intel drivers), but then videos are unwatchable.

Its also strange that linux mint doesnt have this bug, and arch linux has.

@startas No, I'm getting it on Mint 17.

Even weirder since i posted in this issue, i havent had the issue again. I have since installed cinnamon on several differant devices, hardware, and software(distros) configurations.

Its weird - i "solved" this issue (i have only intel hd graphics, so it only might work for intel graphics) by recompiling xf86-video-intel with flag "--disable-dri3", and recompiling lib32-mesa with same flag "--disable-dri3", of course you must also remove flag "--enable-dri3".
While i'm using 64 bit linux, compiling 64 bit mesa package without dri3 and installing it crashes cinnamon desktop, but somehow recompiling only xf86-video-intel and 32 bit version of mesa for 64 bit systems "fixed this issue", it also fixed huge lags in chrome.
Only disabling dri3 in 2d drivers doesnt work, but disabling dri3 in 32 bit version of mesa and installing it worked, i wonder why - this package is not even installed by default, as 64 bit linux uses 64 bit cinnamon, so it uses 64 bit mesa, and i have no idea how it worked :D

except there is one issue with that, DRI3 didnt exist when this issue was first created.

Currently arch linux also diables DRI3 by default i think?

This issue feels like it might be related to something I see in Kerbal Space Program on Linux (with Cinnamon): perfect frameworks, except when I click and hold the mouse to pan around a rocket - then it stutters and jumps badly. Cinnamon is perhaps doing some kind of blocking in the redraw loop for mouse events?

In arch linux, xf86-video-intel is compiled without dri3, but mesa is compiled with dri3.

on my quite fast pc, resizing windows with cinnamon is a pain and i would love an option to disable the realtime visualization of the content of the window. xfce does this in a very good way.

This is happening but only on my external monitor, on a Macbook ("late 2014") with intel graphics. The window will also display tearing artifacts, again only on the external display. The lag does not noticeably change if I enable "TearFree" but it does fix the tearing. I am scaling the external display up 2x2 with xrandr.

edit: I should note that something like glxgears does not suffer reduced framerate if I drag it around on that display, in fact it was reporting ~71 fps on a 60Hz monitor, despite the movement making it look <10 frames per second. Leaving it alone it performs normally.

edit2: it appears the scaling does not change the lag either.

@wrouesnel and others...

The KSP issue specifically is probably due to your mouse polling rate being set too high, particularly if you have a gaming mouse, such as a Razer DeathAdder or similar (which I use). The following tutorial should help:

https://patrickmn.com/aside/lowering-gaming-mouse-sensitivity-in-ubuntu-9-10/

I've recorded a video showing issue I have (Chromium browser dragging issue, while Nemo and Firefox are runned for comparison only): https://youtu.be/Ec99EYjwiqY
I have the same issue with IntellJ and sometimes with Pidgin or less times with Nemo. I am using Mint 17.3 and Cinnamon 2.8.6 with amd propietary drivers. Things to note:

-Mint 17.3 with Cinnamon 2.8.6
-couldn't load opensource gpu drivers to test them, it kept me in software rendering mode now (I remember xorg open source worked fine when I've installed 17.0 Mint back few months ago)
-Forcing disabled vsync in amd propietary CCC help little less laggy windows, but it makes screen tearing especialy while scrolling websites
-When Cinnamon just started everything works fine, no laggy dragging windows, no laggy resizing. The issue is present after some time (for example 10-40 minutes after Chromium was started)
-Restarting Cinnamon (ctrl + alt + esc) does help temporary (above point)
-(edit): it did not happen before on 17.2 and Cinnamon 2.6 if I remember correctly, but I had bigger tearing problem back then.

Edit:
The same things happes using opensource drivers, managed to re-install them.

Running fresh Mint 17.3 Cinnamon from USB stick, the same issue as explained above.
Checked Ubuntu Gnome3 and Ubuntu Mate for comparison. While running both from USB for quite long time I haven't noticed any issues/slowdowns.

Somehow it looks like it is related to GPU, happens especially to software which have GPU support, like Chromium.
Second thing to note is, it looks like it happens faster while having intelihide for menubar and keep punching menubar with Chromium window. I can hear fans in laptop start to work louder. Best to drag Chromium window by circulating over desktop.

"Disable composing for fullscreen windows" enabled/disabled - no change

It is slow to repruduce even with punching menubar, easiest way is to simply browse Internet for some time, but I understand it could be hell for debugging.

I have this issue too - but what I noticed is that windows get _laggy_ after some time - but if I open new ones they don't _lag_.

For example if I let a terminal sit there for say an hour it will stutter while dragging quite a bit, but a newly opened terminal will behave just fine.

And yes that's when I have chrome open (which is basically open all the time).

It's no big deal as every other aspect seems to work fine (for example you don't notice more lag in games or something) - the only other strange thing I noticed is that the lock screen takes about 10sec. to load (I never noticed that before I ugraded to Mint 17.3)

PS: I noticed that the cinnamon --replace process will show quite high CPU usage (around 16% on my system) some time after I moved a _laggy_ window around.

Disabled intellihide, set panel to always show. Running currently OS for few hours and surprise! no lags! I just feel like in heaven.

I can confirm the lag of the window behind cursor, in Linux Mint 17.3, Cinnamon 2.8.6, with nvidia 352.63 proprietary driver. Very annoying! The problem is independent of compositing enabled or not!

I can also confirm the lag with Mint 17.3, Cinnamon 2.8.6 and integrated Graphics of i5-4210U or a nVidea GeForce 820M.
I played a little with the show/hide panel settings and it appears that the lag is only there when the panel is shown. When I set it to auto-hide all window drags are smooth.
(Yeah I know this is the complete opposite of the comment from DarekDeo).

Maybe not complete opposite, from both of our comments looks like something is wrong with the panel. :)

edit: or at least related to it.

I have this issue as well. Anyone try a different graphics driver? I had this problem on Xubuntu 15.10 and once I changed the driver, everything worked fine. I can't seem to find that option here? I go to drivers in settings panel and a blank list just shows up.

Setup: Fedora 23, Cinnamon, GDM, Nvidia proprietary drivers (also with Nouveau)

I am also experiencing stuttering when dragging windows, and also when typing or scrolling through a file in Vim. For instance, while I type, a few letters will appear with the keystroke, then the cursor will hang for a few milliseconds, and then the letters I typed during the hang all appear.

The stuttering seems to happen regularly. If I had to guess, I'd say about every 500 ms. Interestingly, if I move a window around quickly for a period of time, top shows Xorg sometimes taking a huge percentage of the CPU (~53%) when moving windows...this does not seem right. Any ideas?

EDIT: I booted up the Fedora 23 Cinnamon Spin Live CD and interestingly, did not encounter any stuttering. But, using the same DM environment (Cinnamon, lightdm, nouveau drivers) in my HDD installation still does. I may try installing the Cinnamon spin directly off the Live CD on a different machine to see if the problem persists; I will report back with any results.

Wow, okay. Thanks @DarekDeo this works much better when the smart panel is disabled. Just a shame I can't watch Youtube videos in the large player when my browser is fullscreened now, which is why I turned that panel on in the first place, but the windows were getting bad.

I find it strange how laggy all windows still are though, they're not unbearable, but if I go back to Windows my 144hz makes everything look and feel so smooth, moving windows around and they all feel so solid and stable, come back on Linux and my 60 almost feels smoother than my 144 and windows feel like they're meant to be laggy when you're dragging them around.

I also just want to add that the intelligent panel seems to affect windows as well, my browser had been flickering white full on glitching out a lot, went through a few trying them out to see which one no longer experienced it, thought something might be broken with cinnamon or my graphics driver, turns out the panel was the problem @_@

Well that's interesting, I noticed the stuttering I was seeing seemed to happen at the same frequency as the System Monitor applet was updating, so I removed it from the panel and rebooted, and now the stutter has gone away for me. This seems to further support @DarekDeo 's suggestion that something might be wrong with the panel. Maybe, whatever process/thing is updating it is hanging briefly during its redraw loop (I am not a graphics programmer)?

I have the same issue actually, updating to a newer version of Cinnamon made it a bit better but my Nvidia desktop (i5-3570k, Nvidia 780ti) is still not as smooth as my much less powerful Intel graphics laptop (i7-4500u, Intel graphics 4400).

Both of them are running Mint 17.3, Cinnamon 3.04 (nightly channel), and the 4.4.0-22 kernel.

The drivers used are Nvidia's 364 (364.19-0ubuntu0~gpu14.04.3) from the Nvidia drivers PPA and the Intel drivers included in the kernel.

@davidva-cml thank you, removing Sytem Monitor applet solved problem for me!

Turned off "sync to vblank" in the nvidia xserver settings and resizing apps like Telegram is smooth as butter now

This is still a problem for me.
I'm using a fresh install of Ubuntu 16.04.1, using an Nvidia GTX 1070 with driver version 375, so performance shouldn't be an issue.

@JosephMcc, can we mark this issue as a bug?

@davidva-cml Did you manage to get it fixed? I also see Xorg on top of CPU usage when dragging windows... Maybe we should report it as a Xorg issue. Although it could always be a Cinnamon issue afterall.. The simplest way to reproduce is to run glxgears on the background while dragging windows around.

However, some people within this issue could suffer from a totally different lagg issue (which could be Cinnamon related).

I'm afraid that i have the same issue. But i have a really powerful PC (Core i7-5930K 3.5GHz 6 cores + Nvidia TITAN X running the latest nvidia driver + 32 GB of RAM and my OS ins installed on a SSD). So performances shouldn't be an issue. But still, every time i'm trying to drag a window, i have slowness like everyone else in this thread. But the most open apps i have the more slowness it is !
When i monitor (htop) i can se that the Xorg process take 90% or more of CPU usage. So it could come from Xorg, not cinnamon directly.
It should be great to have feedback to understand what is going on there.
Thanks.

Running :
Linux kernel 4.10.0-generic
FerenOS (which is using the latest version of Linux Mint distro)
Running cinnamon 3.4.6

I'm curious if others have figured out any work arounds for this lately as this has gone quiet.

For me, Cinnamon begins destablizing with this lag growing from reboot over time, until it gets almost too annoying to take anymore, and usually I find I have to reboot it hard as the screen won't wake up from sleep any longer. Like the last post, it's a powerful computer (20 cores, 40 threads, dual xeon, 128gb ram, nvidia 1070, dual nvme, 3x 4k displays), so performance is not an issue, and I don't get this with other desktop environments other than kde (which has it's own compositing issues). I've turned off vblank and most other gl features, and still destabilizes, usually within a week, but never any errors to telltale toward something.

I'm using Arch linux, Cinnamon 3.8.1-1, 4.16.13 kernel, and nvidia 396.24 drivers. I keep upgrading hoping this goes away, but never does.

Apparently (as is with most every desktop now) the answer is to simply use software rendering of the desktop. I managed to go a few weeks last time before I was getting a 5 second display timeout about every minute or so, which becomes rather infuriating over time.

Usually I just flip to a different desktop, KDE (praying they fix it too) or Mate (marco tends to behave, but the desktop is otherwise lacking vs. others) after a pacman -Syyu, but this time I noticed the cinnamon software render mode. After a week of normal use with software render, I'd normally start getting the lag after a few days, but with software mode, it's been smooth, and really see no downside in performance in desktop use.

It's a shame this compositor bug seems to persist, but is almost certainly video/gl related. Compositors are the bane of every linux desktop I find, I've yet to find one that behaves properly, even windoze aero I found in 4k is absolute crap that shipped with my xps 9560.

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.

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.

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.

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.

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.

@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.

@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.

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.

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.

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.

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.

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.

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?

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...

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!

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:[email protected]:0', 'panel1:left:1:[email protected]:1', 'panel1:left:2:[email protected]:2', 'panel1:left:3:[email protected]:3', 'panel1:right:0:[email protected]:4', 'panel1:right:1:[email protected]:5', 'panel1:right:2:[email protected]:6', 'panel1:right:3:[email protected]:7', 'panel1:right:4:[email protected]:8', 'panel1:right:5:[email protected]:9', 'panel1:right:6:[email protected]:10', 'panel1:right:7:[email protected]:11', 'panel1:right:8:[email protected]:12', 'panel1:right:9:[email protected]:13', 'panel1:right:10:[email protected]:14']
[user@host ~]$ gsettings get org.cinnamon enabled-desklets
['[email protected]: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.

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.

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.

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

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

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

@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!!

@zenfulcoder 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.

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