Cinnamon: 拖动窗口时窗口重绘滞后

创建于 2013-10-14  ·  73评论  ·  资料来源: linuxmint/cinnamon

单击并拖动窗口时,我使用的Cinnamon 2.0.2和所有较早版本似乎处理过多。

当滑动窗口时,这表现为轻微但明显的结结,这使桌面体验显得很滞后-当我从Cinnamon引导进入Windows 7时,这非常引人注目,其中Windows可以平滑地滑动。

如果我从头开始监视肉桂加工过程,则可以看到CPU使用率,而没有拖动,但是像播放YouTube视频这样的操作大约占5-10%。 当我开始拖动窗口(一个充满文本的Chrome窗口)的那一刻,CPU使用率跃升到大约30%。

最有用的评论

有趣的是,我注意到我看到的卡顿现象似乎与系统监视器小程序的更新频率相同,因此我从面板上将其删除并重新启动,现在卡顿对我来说已经消失了。 这似乎进一步支持了@DarekDeo的建议,即面板可能有问题。 也许,无论正在更新什么进程/事物,它在重绘循环中都会短暂地挂起(我不是图形程序员)?

所有73条评论

我不想说“我也是”,但是...“我也是!” 我在一个稍旧的盒子上运行,而Cinnamon在Ubuntu 13.04之上运行。 其他一切似乎都正常,只是拖动窗口是个问题。 而且“口吃”很明显,此后窗口仅跳至下一个点。 拖动任何窗口(chrome,uxterm)时似乎都会发生。 让我知道我可以提供哪些其他支持信息。 我在系统日志中找不到任何有趣的东西。

我可以确认这一点,但是我的显卡很差...

我也遇到了同样的问题。 我正在从Ubuntu 13.10的每晚PPA运行最新的Cinnamon。

我目前在使用肉桂2.0.2的arch Linux上运行多头系统(3x 1920x1080),我已经尝试了660和7870。它们都表现出相同的行为,在移动或调整大小时会出现很大的滞后窗口。 我正在使用开源驱动程序atm。 (一旦更新工作,将尝试使用催化剂)

在我的系统上,它几乎无法忍受。

---更新---如果我在“肉桂设置”面板中禁用->“窗口平铺和边缘翻转”->“窗口平铺和捕捉”,则窗口将再次在屏幕上快速移动; 我在一个窗口中移动时得到了这个提示,我得到了新的HUD东西,向我展示了可以放置该窗口的位置。 每当HUD出现时,滞后都会启动。

我可以在笔记本电脑上确认相同的行为; 使用Manjaro Linux和Cinnamon 2.0.6
我有一个双核P6100 CPU和一个Intel HD 3000图形卡。
我在1.6或1.8之前没有这个问题。
我一直在寻找使用Muffin的选项,以便在移动时禁用“窗口内容”,但到目前为止,还没有运气,使用Dconf编辑器。
如果有人能解释为什么会发生,那就太好了。
保持良好的工作 ;)!

与调整窗口大小(例如:gnome-terminal)相比,窗口拖动的延迟没有任何意义,它可能需要几秒钟:-(

我使用Intel Core I5和Intel图形控制器(第二代)确认了此错误。

您可以将平铺HUD阈值设置为1,它实际上将禁用HUD显示,同时仍保持启用平铺功能。 也许在下一版本中,可以添加更直接的禁用它的方法,以及用于动画HUD的更强大的图形集。

我可以在i7-2600K CPU和AMD R9 290 GPU(最新beta驱动程序)上确认此错误。 特别是在我的120hz屏幕上。 禁用平铺和捕捉没有帮助。

您正在运行什么版本的Cinnamon? 原因之一是最近才修复的。

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

我正在运行Cinnamon 2.0.14。 将尝试安装最新的。

拥有最新的松饼可能更重要。 如果您使用的是松饼2.0.4,则还没有解决方法。 如果您运行2.0.5,它将拥有它。

(我不保证您的特定问题已得到解决,可能是其他原因造成的,但是值得检查)

我在薄荷16上使用带有Intel HD 4600显卡的i5-4440的Cinnamon 2.0.14和Muffin 2.0.5遇到了类似的情况。 当我拖动Windows时,它们无法跟上鼠标光标。 就像窗户是用小的橡皮筋附着在我的光标上一样。

这是我所经历的视频。 这是正常行为吗? http://youtu.be/KylzMTZpD7w

我可以确认这种情况对于Debian Jessie上的Cinnamon 2.2.14和Gnome Shell 3.12.2仍然有效。

我也明白这一点,说实话确实让人分心。 明显不如Unity等,甚至Windows都不如...

使用NVidia GTX 760也遇到了我以前抱怨过的相同问题。对于多台显示器,问题肯定会更加严重。

我也可以在Cinnamon 2.2.14上使用带有专有驱动程序版本340.24(和两个显示器)的NVidia GT 630来获得。 降级到驱动程序版本304时,窗口再次快速移动,但是随后我感到眼泪汪汪。

在美国东部时间2014年8月10日星期日凌晨04:04:47,Andres Manz写道:

我在Cinnamon 2.2.14上也可以通过带有NVidia GT 630的
专有驱动程序版本340.24(和两个监视器)。 降级时
到驱动程序版本304,窗口再次快速移动,但随后我
体验流泪。

通过禁用垂直同步时,窗口拖动滞后消失
环境变量。 AFAIK Nvidia驱动程序304无法通过以下方式启用vsync
默认值(与更新的值不同),因此它可以解释为什么您拥有快速
降级时会拖拉和撕裂。

但是,无论vsync如何,CPU使用率很高。

如果我不尝试启用vsync(intel驱动程序),则可以确认Windows的延迟时间要少得多,但是视频无法观看。

linux mint没有这个错误,而arch linux也没有。

@startas不,我在Mint 17上得到它。

自从我在这个问题上发布以来,甚至更奇怪,我再也没有这个问题。 从那以后,我在几个不同的设备,硬件和软件(distros)配置上安装了肉桂。

怪异的-我通过用标志“ --disable-dri3”重新编译xf86-video-intel并用相同的方法重新编译了lib32-mesa,从而“解决”了这个问题(我只有intel hd图形,因此它仅适用于intel图形)标志“ --disable-dri3”,当然,您还必须删除标志“ --enable-dri3”。
当我使用64位linux时,不使用dri3编译64位mesa程序包并安装它会导致肉桂桌面崩溃,但是以某种方式仅针对64位系统重新编译了xf86-video-intel和32位版本的mesa可以“解决此问题”,修复了铬合金的巨大滞后。
仅在2d驱动程序中禁用dri3不起作用,但是在32位版本的mesa中禁用dri3并安装它起作用,我想知道为什么-默认情况下甚至没有安装此软件包,因为64位linux使用64位肉桂,所以它使用64位台面,我不知道它是如何工作的:D

除了有一个问题外,首次创建此问题时不存在DRI3。

目前,我认为默认情况下,arch linux还会禁用DRI3。

这个问题似乎与我在Linux上的Kerbal Space Program(带有Cinnamon)中看到的东西有关:完美的框架,除了当我单击并按住鼠标以围绕火箭平移时-然后结结巴巴并严重跳动。 肉桂可能在鼠标事件的重绘循环中进行了某种阻止?

在arch linux中,xf86-video-intel不使用dri3进行编译,而mesa是使用dri3进行编译的。

在我相当快的PC上,用肉桂调整窗口大小是很痛苦的,我希望可以选择禁用窗口内容的实时可视化。 xfce很好地做到了这一点。

这只是在我的外接显示器上,即在具有英特尔图形处理器的Macbook(“ 2014年末”)上发生。 该窗口还将在外部显示器上再次显示撕裂的伪影。 如果启用“ TearFree”,则延迟不会明显改变,但可以解决撕裂问题。 我正在使用xrandr将外部显示器放大2x2。

编辑:我应该注意,如果我在显示器上拖动类似glxgears的帧,它的帧率不会降低,实际上,它在60Hz监视器上的报告帧率为〜71 fps,尽管移动使其每秒显示<10帧。 不管它如何正常运行。

edit2:似乎缩放比例也不会更改滞后。

@wrouesnel和其他人...

特别是KSP问题可能是由于您将鼠标轮询速率设置得太高,特别是如果您有游戏鼠标,例如Razer DeathAdder或类似鼠标(我使用的是)。 以下教程应有所帮助:

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

我录制了一段视频,显示了我遇到的问题(铬浏览器拖动问题,而运行Nemo和Firefox只是为了进行比较): https :
我对IntellJ有相同的问题,有时对Pidgin也有相同的问题,而对Nemo则更少。 我将Mind 17.3和Cinnamon 2.8.6与AMD专有驱动程序一起使用。 注意事项:

-薄荷17.3和肉桂2.8.6
-无法加载开源gpu驱动程序进行测试,它现在使我进入了软件渲染模式(我记得几个月前我安装了17.0 Mint时xorg开源工作得很好)
-在AMD专有CCC中强制禁用vsync可以帮助减少滞后窗口,但是在滚动网站时,它尤其会导致屏幕撕裂
-肉桂刚开始时,一切正常,没有拖拉窗口,没有调整大小。 一段时间后(例如,启动Chromium后10-40分钟),此问题仍然存在
-重新启动Cinnamon(ctrl + alt + esc)确实可以帮助临时操作(高于该值)
-(编辑):如果我没记错的话,它在17.2和Cinnamon 2.6之前从未发生过,但是那时候我的撕裂问题更大。

编辑:
使用开源驱动程序,同样的事情会发生,并设法重新安装它们。

使用USB记忆棒运行新鲜的Mint 17.3肉桂,与上述问题相同。
检查了Ubuntu Gnome3和Ubuntu Mate进行比较。 通过USB运行这两种设备很长时间了,我没有发现任何问题/速度变慢。

看起来与GPU有关,特别是发生在具有GPU支持的软件(例如Chromium)上。
要注意的第二件事是,在使用菜单栏智能化并持续使用Chromium窗口打孔菜单栏时,它发生得似乎更快。 我可以听到笔记本电脑中的风扇开始更大声工作。 最好通过在桌面上循环拖动Chromium窗口。

启用/禁用“禁用全屏窗口撰写”-不变

即使打孔菜单栏也很难恢复,最简单的方法是简单地浏览Internet一段时间,但是我知道调试可能很麻烦。

我也有这个问题-但我注意到的是一段时间后Windows会变得_laggy_-但如果我打开新窗口,它们就不会_lag_。

例如,如果我让一个终端坐在那里一个小时,它会在拖拉很多时结结巴巴,但是新打开的终端会表现良好。

是的,那是我打开chrome的时候(基本上一直都是打开的)。

没什么大不了的,因为其他各个方面似乎都可以正常工作(例如,您没有注意到游戏或其他方面的更多滞后)–我注意到的唯一其他奇怪的事情是锁定屏幕大约需要10秒。 加载(在升级到Mint 17.3之前,我从未注意到)


PS:我注意到cinnamon --replace进程在移动_laggy_窗口一段时间后会显示出很高的CPU使用率(在系统上约为16%)。

禁用智能,将面板设置为始终显示。 当前的操作系统运行了几个小时,令人惊讶! 没有滞后! 我就像在天堂一样。

我可以使用nvidia 352.63专有驱动程序在Linux Mint 17.3,Cinnamon 2.8.6中确认光标后面的窗口滞后。 很烦人! 该问题与是否启用合成无关!

我还可以用Mint 17.3,Cinnamon 2.8.6和i5-4210U或nVidea GeForce 820M的集成Graphics来确认滞后性。
我在“显示/隐藏”面板设置中进行了一些操作,似乎只有在显示面板时才出现延迟。 当我将其设置为自动隐藏时,所有窗口拖动都是平滑的。
(是的,我知道这与DarekDeo的评论完全相反)。

可能并非完全相反,从我们两个的评论看来,面板都有问题。 :)

编辑:或至少与此有关。

我也有这个问题。 有人尝试其他图形驱动程序吗? 我在Xubuntu 15.10上遇到了这个问题,更换驱动程序后,一切正常。 我似乎在这里找不到该选项? 我转到“设置”面板中的驱动程序,然后出现一个空白列表。

设置:Fedora 23,Cinnamon,GDM,Nvidia专有驱动程序(也适用于Nouveau)

在拖动窗口以及在Vim中键入或滚动文件时,我也遇到了卡顿现象。 例如,当我键入内容时,按键会出现几个字母,然后光标将挂起几毫秒,然后我在挂起过程中键入的所有字母都会出现。

口吃似乎经常发生。 如果我不得不猜测,我大概每500毫秒说一次。 有趣的是,如果我快速移动窗口一段时间,top显示Xorg在移动窗口时有时会占用很大一部分CPU(〜53%)……这似乎不正确。 有任何想法吗?

编辑:我启动了Fedora 23 Cinnamon Spin Live CD,有趣的是,没有遇到任何卡顿现象。 但是,在我的HDD安装中仍然使用相同的DM环境(Cinnamon,lightdm,nouveau驱动程序)。 我可能会尝试直接在另一台计算机上的Live CD上安装Cinnamon Spin,以查看问题是否仍然存在。 我将报告任何结果。

哇好谢谢@DarekDeo,当禁用智能面板时,此方法效果更好。 遗憾的是,当我的浏览器现在全屏显示时,我无法在大型播放器中观看Youtube视频,这就是为什么我首先打开该面板但窗口变坏的原因。

我觉得很奇怪,尽管所有窗户仍然很不整齐,它们并不是无法忍受的,但是如果我回到Windows,我的144hz会使一切看起来和感觉都那么平滑,移动窗户,它们都感觉如此牢固和稳定,然后重新打开Linux和我的60几乎比144和Windows光滑,当您拖动它们时,它们似乎注定要笨拙。

我还只是想补充一点,智能面板似乎也影响了Windows,我的浏览器一直闪烁白色,出现了很多故障,经历了几次尝试以查看哪个不再体验,以为是用肉桂或我的图形驱动程序损坏了,原来是面板问题@ _ @

有趣的是,我注意到我看到的卡顿现象似乎与系统监视器小程序的更新频率相同,因此我从面板上将其删除并重新启动,现在卡顿对我来说已经消失了。 这似乎进一步支持了@DarekDeo的建议,即面板可能有问题。 也许,无论正在更新什么进程/事物,它在重绘循环中都会短暂地挂起(我不是图形程序员)?

我实际上也有同样的问题,更新到较新版本的Cinnamon会使它更好一些,但是我的Nvidia台式机(i5-3570k,Nvidia 780ti)仍然不如我的功能较弱的Intel图形笔记本电脑(i7-4500u,Intel)光滑图形4400)。

他们两个都运行Mint 17.3,Cinnamon 3.04(每晚频道)和4.4.0-22内核。

使用的驱动程序是Nvidia驱动程序PPA中的Nvidia 364(364.19-0ubuntu0〜gpu14.04.3)和内核中包含的Intel驱动程序。

@ davidva-cml谢谢,删除Sytem Monitor applet为我解决了问题!

在nvidia xserver设置中关闭“与vblank同步”,重新调整Telegram等应用的大小就像黄油一样流畅

这对我来说仍然是一个问题。
我使用的是全新安装的Ubuntu 16.04.1,使用驱动程序版本为375的Nvidia GTX 1070,因此性能应该不是问题。

@JosephMcc ,我们可以将此问题标记为错误吗?

@ davidva-cml您是否已解决问题? 在拖动窗口时,我还会在CPU使用率之上看到Xorg ...也许我们应该将其报告为Xorg问题。 尽管毕竟这始终可能是肉桂问题。.最简单的重现方法是在背景上运行glxgears并同时拖动窗口。

但是,此问题中的某些人可能会遇到完全不同的滞后问题(可能与肉桂有关)。

恐怕我有同样的问题。 但是我有一台非常强大的PC(Core i7-5930K 3.5GHz 6核+运行最新nvidia驱动程序的Nvidia TITAN X + 32 GB RAM和我的OS安装在SSD上)。 因此表演不应该成为问题。 但是,每次我尝试拖动一个窗口时,我都会像该线程中的其他所有人一样感到迟钝。 但是,最开放的应用程序,我的速度更慢!
当我监视(停止)时,我可以确定Xorg进程占用了90%或更多的CPU使用率。 因此它可能来自Xorg,而不是直接来自肉桂。
收到反馈以了解正在发生的事情应该很棒。
谢谢。

正在运行:
Linux内核4.10.0通用
FerenOS(正在使用最新版本的Linux Mint发行版)
运行肉桂3.4.6

我很好奇是否其他人最近发现了任何解决方法,因为它变得安静了。

对我来说,肉桂随着开始重新启动的滞后时间而变得不稳定,直到变得几乎烦人以至无法再忍受,通常,我发现我不得不重新启动它,因为屏幕将无法再从睡眠中唤醒。 就像上一篇文章一样,它是一台功能强大的计算机(20核,40个线程,双至强,128GB ram,nvidia 1070,双nvme,3x 4k显示器),因此性能不是问题,在其他台式机上我不会遇到这种情况kde以外的环境(这是它自己的合成问题)。 我已经关闭了vblank和大多数其他gl功能,并且通常在一周内仍然不稳定,但是从来没有任何错误可以说明问题。

我正在使用Arch Linux,Cinnamon 3.8.1-1、4.16.13内核和nvidia 396.24驱动程序。 我一直在升级,希望这一切能够消失,但是永远不会。

显然(就像现在大多数台式机一样),答案是仅使用台式机的软件渲染。 上一次我设法走了几周,直到大约每分钟才有5秒的显示超时时间,随着时间的流逝,这变得非常令人生气。

通常,在pacman -Syyu之后,我只是翻到另一个桌面,KDE(还希望他们也修复它)或Mate(marco往往表现良好,但相对于其他桌面,它还是缺少桌面),但是这次我注意到了肉桂软件渲染模式。 在正常使用软件渲染一周后,通常几天后我就会开始滞后,但是在软件模式下,它运行起来很流畅,并且在桌面使用方面确实看不到任何性能下降。

很遗憾,这个合成器错误仍然存​​在,但是几乎可以肯定与video / gl有关。 合成器是我发现的每一个Linux桌面的祸根,我还没有找到一种运行正常的方法,即使我在4k中发现的windoze aero也是xps 9560附带的绝对废话。

一个好的解决方法是将CLUTTER_VBLANK=none到/ etc / environment,并在显示配置->高级下的nvidia-settings中的所有监视器上启用强制组合管道。 这将垂直同步处理从合成器移至驱动程序,并在xorg配置中启用TearFree同时对amdgpu有所帮助。

为此,我在/ etc / environment中进行了设置,但是我发现不需要尝试使用硬件渲染的版本,因为它似乎只会引起戏剧性和混乱。 到目前为止,我对软件渲染的版本非常满意,在cairo-dock和其他一些应用程序中出现了一些绘图延迟,但并不十分讨厌像自发的硬件版本。

有趣的是,即使在现在的软件模式下,我也在开发相同的滞后,但是速度要比使用完整gpu渲染慢得多。 感觉有些资源泄漏,但是如果不直接针对gpu进行渲染,我会假设桌面中的资源管理中存在一些错误。

有什么有用的反馈,日志,调试等可帮助解决此问题? 除了台式机每隔随机/公用间隔突然跳动外,我在任何地方都看不到任何异常。

同样要澄清的是,我认为这很大程度上与我使用的高分辨率有关。 我的台式机运行在11520x2160(3x 4k显示器)上,这给我发现甚至尝试gpu加速的任何台式机都增加了负担。 我认为没有人会考虑这种事情,但是随着4k,5k和8k的出现,这种斗争是真实的。 这就是为什么合成似乎在任何桌面下都无法使用的原因,包括在这种规模下直接针对gpu进行渲染的情况下,包括unity,kde,肉桂甚至mate / marco。

开发人员需要注意的是,自2010年以来,随着合成技术的出现,我将在Linux下运行6x 1080p显示器,正确合成分辨率的分辨率比例一直是一个问题。

因此,在经过大约80天的正常运行时间后,最近一次在使用软件进行软件合成的窗口重绘上遇到了5秒钟的延迟之后,我再次回来进行检查。 长话短说:没那么多。

现在是4.0.7核心的肉桂包,并且像以前一样使用软件渲染启动时,窗口周围部分出现了可怕的闪烁和怪异的刷新问题(例如,最小/退出按钮),真是太糟糕了。 尝试硬件模式时,它可以在没有这种模式的情况下工作,但是几乎立即,我在使用后的几天内就开始出现刷新滞后,并且与以前驱使我使用软件的硬件模式一样,它一直在稳定增长。 到目前为止,软件在4.0中似乎只是一个篮子,但是硬件渲染仍然可以追溯到几年前。

实际解决此问题可能需要什么? 显示器的分辨率并没有变小,而且这些合成器似乎无法处理旧的高清分辨率以外的任何问题。

@mikebutash从来没有打算在加载图形驱动程序时使用软件渲染模式。 用于VGA模式。

有各种各样的PR可供4.2使用。 如果您愿意对它们进行测试,则可以在Muffin存储库中检出我的PR分支。 另一个选项是在“设置”->“常规”中禁用vsync,并在nvidia-settings中启用强制合成管道。 对于4.0.x系列,没有其他可修复的方法。

编辑:另请参阅此Wiki页面

@jaszhix同意这不是要解决方案,而是说它比首选的硬件方法更好,尤其是随着时间的推移。 但是在较新的4.0上并没有那么多,随着闪烁和极端滞后的出现又发生了另一次回归,立即在硬件上又开始了增量滞后。 随着时间的流逝,事实变得越来越糟,这表明代码不稳定,这是从3.x早期开始就可能发生的,甚至可能到4.2为止,所以我怀疑我实际使用的版本是否重要。

我之前已经按照建议进行了vsync和强制管道操作,但是现在确实注意到检查,因为在nvidia设置中再次禁用了强制全合成管道,因此重新启用并会看到效果如何。 在所有显示器上启用它后,我仍然仍然会偶尔看到延迟,尽管还有待观察它是否会逐渐趋于恶化。

如果所有DE都非常擅长于合成,那么如果它们能够确保分辨率的大规模稳定性,那就太好了,因为它们大多数都在高分辨率下遇到相同的问题。 我的Cinnamon就像是内存泄漏,大约90天后在重新启动/升级之前,我会看到Cinnamon台式机通常使用80-90%的cpu来处理htop中的top-talker(似乎没有线程)我可以使用39个其他线程,因此在内核方面表现很好),并使用了很多内存,大约20-30gb(在这个系统中可以说是128gb)。 需要有一种大规模测试此方法的方法,并且看起来像某种类似于valgrid的压力测试。 在这里使用90天左右后,肉桂随时可以弹出,并且位于软件渲染中。 通常会在一周内死于硬件。 KDE遭受的痛苦几乎相同。

大多数人通常不会运行分辨率为11200x2160的显示器,但这只是3x 4k显示器,它们每天变得越来越普遍和便宜,或者自行调整。 在某些时候,堆肥需要考虑这样的分辨率以及更高的分辨率,并具有长期稳定性,或者找出一种更适合大众的折衷方法。 宁可在我的窗口上有稳定的重绘,也不会随着时间的过去对其进行摆动/透明化。 如果我知道造成系统不稳定的原因,那么我很乐意禁用它。

您的Nvidia驱动程序是什么版本? 如果您使用的是390或396,请在Ubuntu PPA上使用415.25。

我的显示器的综合分辨率为8560x1440,目前我在PR分支机构中没有看到Cinnamon随时间推移而出现任何变慢的情况,在短时间内,我不会重启Cinnamon进行开发。

强制合成管道确实会增加一些延迟。 我通常不建议使用它,如果您在Cinnamon的vsync中遇到问题,请确保在nvidia设置中启用了“允许翻转”,并且禁用了“同步到vblank”。 不要使用适用于3.8及更早版本的驱动程序解决方法。

我不清楚您认为滞后的原因-拖动时光标是否与窗口不同步? 还是Windows的一般输入延迟? 这些东西受合成器代码不同部分的影响。 https://github.com/linuxmint/muffin/pull/397都改进了,而https://github.com/linuxmint/muffin/pull/392则改进了后者-我想进入4.0,但是它需要更多测试。

闪烁和极端滞后的另一个回归

让我们把这些问题区分开,目前已经有几个问题就闪烁,我还没有看到它是在4.0更糟。 当然需要修复,但是很难修复无法可靠复制的内容。

因此,在我上次升级时,我使用的是NVIDIA 415.25-4,因此在您的期望内。

我设置了允许翻转(之前没有做过),禁用了同步到vblank(通常完成)以及在每个显示器上强制完全合成管道(这次检查是重置的)。

滞后,就像我所做的一切。 如果在两个窗口之间单击,则重绘会产生一些滞后,屏幕中的冻结位置一次会停止几秒钟。 我最近一直在玩《霸王》,在战斗中很烦人。 我学会了在发生时注意并抢先。 桌面使用也会导致这种停顿,键入该结果会导致在窗口之间以及键入期间单击的各种滞后/停顿。 在打字过程中或随机进行任何鼠标或键盘活动时,一切都会停止一两秒钟。

拖拉东西会加剧问题,大多数UI东西会激怒和滞后于桌面,视觉上拖延一两秒。 快进90天,这会使您决定击球时的所有动作停滞5秒,即每隔几分钟,有时甚至更短。

关于闪烁,我注意到在所有显示器上都发生了这种情况,随机出现在某些区域,并不总是相同,但是就像过去的某种鬼影区域一样,它会一次开始闪烁几秒钟,然后消失。 这是在4k中的所有3个显示器上进行的,一次只显示一小部分。

看来这是软件渲染的另一个产物,但是这样做时很奇怪。 我还没有在硬件渲染下看到这一点,但是在过去的90天左右的时间里,使用该软件已经做了很多工作。 在硬件下没有软件中怪异事物的情况下足够糟糕。

我设置了允许翻转(之前没有做过),禁用了同步到vblank(通常完成)以及在每个显示器上强制完全合成管道(这次检查是重置的)。

基本上,我的建议是在“设置”->“常规”中重新启用松饼的vsync,并禁用强制完整合成管道。 如果两者都启用,您将遇到最大的滞后。

在软件渲染时以及使用某些在打开时使用的Clutter env变量时,闪烁肯定会更糟。 我没有看到使用nomodeset参数启动时发生这种情况,但是如果在Cinnamon使用软件渲染的同时加载了Nvidia驱动程序,则会发生闪烁。 参见#7985。

“过时的”行为听起来好像线程被间歇性地阻塞了,您是否在使用任何第三方applet / desklet / extensions? 检查gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions

我很困惑,不确定说实话要承受多大的痛苦,否则我通常会感到沮丧。 我倾向于使用它们的发布,升级,并为问题刚刚消失而祈祷。 但是现在不跨主要版本,从3.x到4.0。 我尽量不要偏离很大,我以这个系统为生,其中包括各种VPN,虚拟机以及与此相关的各种其他集成点。

我没有在硬件下闪烁,尽管它确实会立即启动随机延迟。 我已经知道情况变得越来越糟。

是的,我不得不再次停止使用Cinnamon,仅几天后,窗口重绘滞后就使我丧命,在我一直在使用的任何刷新窗口中,长达5秒钟的滞后都使我丧命。 尝试与此游戏是不可能的。 通常,我会回到软件渲染,通常花几个月的时间才能达到相同的长时间更新延迟,但是现在4.0版中的软件渲染完全不可用。

值得一提的是,KDE / Kwin仍然是一个问题,几乎是相同的问题,但是我根本不会完全刷新窗口,而必须最小化并重新选择窗口以进行任何更改以重新绘制。

为什么不同DE中的合成器真的很难做到?

我确实检查了第3方扩展名,不,我只剩下肉桂扩展名,而且大多数都是默认扩展名。 我通常将cairo-dock覆盖在上面,并用于定制商品。

我花了很多时间来观察htop,iotop,nvtop和powertop,还有其他人试图找出这种情况的原因,但是我从来没有看到任何特别的东西以任何形式出现在肉桂桌面之外的资源猪中本身,以及随着时间的推移xorg。

当然,这总是变得模糊不清,xorg,nvidia驱动程序或肉桂的异常行为有多少? 我不知道在内部进行调试的任何好方法。 如果您知道观察这些内部问题的好方法,尤其是肉桂本身,那肯定会随时间流逝,所以我会敞开心ear。

应用程序正在做它们的事情,只有窗口在那些“滞后”时刻不会被重绘,所以我同意某些东西被阻止了,但是我不知道它是什么。

我确实不得不切换到kde,因为滞后最终在这里引起了极大的悲伤,但是kde看起来像没有冠军,所以愿意再次尝试肉桂。 薄荷几乎是太简单了,我不能忍受gnome3,特别是ubuntu的功能失调的版本,因此尽管有这些问题,我还是继续回到肉桂。 如果可能的话,我真的很乐意帮助他们修复,因为显然我并不是唯一一个通过此线程解决问题的人。

我很好奇其他人看到这件事后发生了什么...

为什么不同DE中的合成器真的很难做到?

优化合成很困难,并且需要大量的反复试验。 这根本不是一件容易的事。

我只有肉桂扩展名,而且大多数都是默认扩展名。 我通常将cairo-dock覆盖在上面,并用于定制商品。

大多? 使用了哪些扩展? 这是一个重要的细节。 我们需要可以帮助重现此问题的信息,而不是有关合成的大量文字信息。 谢谢!

似乎有一个启用的桌面,bbcwx,一个天气小程序,但我看不到它存在或在先运行的任何迹象。

[ user @ host〜] $ gsettings获得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启用org.cinnamon-desklet
[' [email protected] :1:50:50']
[ user @ host〜] $ gsettings获得org.cinnamon enabled-extensions @ as []

我确实意识到处理合成是一项复杂的工作,因此我并不意味着轻描淡写,我当然会对此深表赞赏,但是在每个DE中,合成都是我在Linux下使用所有功能中最弱的链接。 即使在Windoze中,Aero也可以用作合成的篮子,这是我在戴尔笔记本电脑中开箱即用的有限使用中发现的。 令人惊讶的是,有多少独特的努力会弄错这一点,所以我只想问为什么在似乎不可能完成足够好的事情时如此必要? 似乎应该有更好的方法。

好的,因此,如果启用了bbcwx但未渲染,则可能行为异常。 我还针对4.0.x打开了一些PR,它们可能会影响性能,例如#8180。 我不确定该何时合并,但每个人都应该使用它,或者切换到GWL。

我了解这种挫败感-这就是为什么我开始学习C以便可以改善松饼的原因,但是除了开放式PR(我一直在做)之外,我无能为力。 通常,Linux上的图形已经落后了很长时间,并且最近在发生一些重大变化(例如质子)之后才开始追赶。 有很多工作要做,我的目标是使松饼像Windows 10中的DWM一样灵敏。

我什至不记得启用它,因此一定是随机的并且被遗忘了。 如果可以的话,我将其删除。

自2006年以来,我一直在全职使用linux,并记得进行合成之前/之后的工作,之前的生活要简单得多。 最初几年,我就一直在处理Ubuntu和Compiz问题,这使我开车去KDE,后来又去了Mate / Cinnamon,现在又来回走了,这比以前少了。

到目前为止,从Cinnamon的3.x到4.0是最糟糕的,但是kwin,compiz,喃喃自语,它们似乎都遭受着一些固有的资源泄漏,随着时间的流逝,情况会越来越严重。 由于他们都这样做,所以我经常怀疑它是一个较低级的组件,例如xorg或nvidia驱动程序,它们导致了所有DE的不稳定,但实际上没有办法。 因此,我从DE开始,但是我也观察了各种* top来试图找出导致这些图形延迟的原因,但到目前为止没有任何效果。

我倾向于遵循arch正常的pacman升级,尝试干净利索地引入更新,不确定是否可以尝试在arch中尝试下一个松饼版本。

我也有这个问题。 查看我的规格截图。 我什至有128GB的RAM: https :

解决了我转向XFCE> <的问题(因此在Cinnamon中未解决)

@zenfulcoder您使用的h * K在哪里使用128GB内存? 可能是您确定要迁移到XFCE的时候了..哈哈

@ danger89是的,我爱XFCE,经过XFCE多年后,我才切换到Cinnamon。 我喜欢Cinnamon用于现代台式机及其集成。 很糟糕,它需要OpenGL才能运行。

好吧,我的董事会支持它,所以我将其放在XD中。 但是那样,对于工作,我永远不会耗尽。 基本上是无限的。 但是它在肉桂上仍然运行缓慢!

@zenfulcoder欢迎来到瓶颈所在。 适当地不是由于您的内存大小,还是可能是内存速度/延迟之类的。 其余的PC(磁盘/主板/ hm ..等)。

不过,正如您在上一节中所看到的,它可能根本与您的规格无关。 视频驱动程序,Xorg或该区域中的某些内容存在错误。

@ danger89这绝对是肉桂的问题。 我读过v4可能更好,但对于Debian来说还不够稳定。

此页面是否有帮助?
0 / 5 - 0 等级