Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window redraw lag when dragging windows #2465

Open
wrouesnel opened this issue Oct 14, 2013 · 73 comments
Open

Window redraw lag when dragging windows #2465

wrouesnel opened this issue Oct 14, 2013 · 73 comments
Labels

Comments

@wrouesnel
Copy link
Contributor

@wrouesnel wrouesnel commented Oct 14, 2013

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

@ccurvey
Copy link

@ccurvey ccurvey commented Oct 16, 2013

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.

@ManIVIctorious
Copy link

@ManIVIctorious ManIVIctorious commented Oct 17, 2013

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

@ScipioAfricanus
Copy link

@ScipioAfricanus ScipioAfricanus commented Oct 19, 2013

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

@mdsitton
Copy link

@mdsitton mdsitton commented Oct 26, 2013

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.

@cunoastere
Copy link

@cunoastere cunoastere commented Nov 4, 2013

---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 ;)!

@leigh123linux
Copy link
Contributor

@leigh123linux leigh123linux commented Nov 4, 2013

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

@hadim
Copy link

@hadim hadim commented Nov 16, 2013

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

@mtwebster
Copy link
Member

@mtwebster mtwebster commented Nov 16, 2013

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.

@devtoi
Copy link

@devtoi devtoi commented Feb 25, 2014

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.

@mtwebster
Copy link
Member

@mtwebster mtwebster commented Feb 25, 2014

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

linuxmint/muffin@403d24e

@devtoi
Copy link

@devtoi devtoi commented Feb 25, 2014

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

@mtwebster
Copy link
Member

@mtwebster mtwebster commented Feb 25, 2014

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)

@andrewfraley
Copy link

@andrewfraley andrewfraley commented Mar 3, 2014

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.

@andrewfraley
Copy link

@andrewfraley andrewfraley commented Mar 5, 2014

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

@mdirik
Copy link

@mdirik mdirik commented Jul 25, 2014

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

@pinumbernumber
Copy link

@pinumbernumber pinumbernumber commented Jul 25, 2014

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

@andrewfraley
Copy link

@andrewfraley andrewfraley commented Jul 25, 2014

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

@andresmanz
Copy link

@andresmanz andresmanz commented Aug 10, 2014

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.

@mdirik
Copy link

@mdirik mdirik commented Aug 10, 2014

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.

@pinumbernumber
Copy link

@pinumbernumber pinumbernumber commented Aug 10, 2014

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

@startas
Copy link

@startas startas commented Aug 10, 2014

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

@pinumbernumber
Copy link

@pinumbernumber pinumbernumber commented Aug 10, 2014

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

@mdsitton
Copy link

@mdsitton mdsitton commented Aug 12, 2014

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.

@startas
Copy link

@startas startas commented Aug 14, 2014

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

@mdsitton
Copy link

@mdsitton mdsitton commented Aug 14, 2014

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?

@wrouesnel
Copy link
Contributor Author

@wrouesnel wrouesnel commented Aug 14, 2014

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?

@startas
Copy link

@startas startas commented Aug 14, 2014

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

@joemaro
Copy link

@joemaro joemaro commented May 10, 2015

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.

@HTL2001
Copy link

@HTL2001 HTL2001 commented May 22, 2015

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.

@tand00ri
Copy link

@tand00ri tand00ri commented Jun 9, 2015

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

@Vahan86
Copy link

@Vahan86 Vahan86 commented Feb 4, 2017

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

@JosephMcc JosephMcc added the BUG label Feb 4, 2017
@danger89
Copy link

@danger89 danger89 commented Jul 3, 2017

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

@JoMas971
Copy link

@JoMas971 JoMas971 commented Sep 23, 2017

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

@mikebutash
Copy link

@mikebutash mikebutash commented Jul 14, 2018

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.

@mikebutash
Copy link

@mikebutash mikebutash commented Jul 24, 2018

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.

@jaszhix
Copy link
Contributor

@jaszhix jaszhix commented Jul 24, 2018

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
Copy link

@mikebutash mikebutash commented Jul 26, 2018

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
Copy link

@mikebutash mikebutash commented Jul 30, 2018

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
Copy link

@mikebutash mikebutash commented Jul 30, 2018

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
Copy link

@mikebutash mikebutash commented Dec 31, 2018

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
Copy link
Contributor

@jaszhix jaszhix commented Dec 31, 2018

@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
Copy link

@mikebutash mikebutash commented Jan 1, 2019

@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
Copy link
Contributor

@jaszhix jaszhix commented Jan 1, 2019

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. linuxmint/muffin#397 improves both, and linuxmint/muffin#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
Copy link

@mikebutash mikebutash commented Jan 1, 2019

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
Copy link

@mikebutash mikebutash commented Jan 1, 2019

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
Copy link
Contributor

@jaszhix jaszhix commented Jan 1, 2019

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
Copy link

@mikebutash mikebutash commented Jan 1, 2019

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
Copy link

@mikebutash mikebutash commented Jan 6, 2019

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
Copy link

@mikebutash mikebutash commented Jan 6, 2019

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
Copy link
Contributor

@jaszhix jaszhix commented Jan 6, 2019

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
Copy link

@mikebutash mikebutash commented Jan 6, 2019

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
Copy link
Contributor

@jaszhix jaszhix commented Jan 6, 2019

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
Copy link

@mikebutash mikebutash commented Jan 6, 2019

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
Copy link

@sgtcoder sgtcoder commented Oct 21, 2019

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

@danger89
Copy link

@danger89 danger89 commented Oct 21, 2019

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

@sgtcoder
Copy link

@sgtcoder sgtcoder commented Oct 21, 2019

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

@danger89
Copy link

@danger89 danger89 commented Oct 21, 2019

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

@sgtcoder
Copy link

@sgtcoder sgtcoder commented Oct 21, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet