Cinnamon: ウィンドウをドラッグするときのウィンドウの再描画ラグ

「私も」とは言いたくないけど…「私も！」 私はやや古いボックスで実行しており、CinnamonはUbuntu13.04上で実行されています。 それ以外はすべて問題ないようです。問題となるのはウィンドウのドラッグだけです。 そして、「スタッター」が目立ち、その後、ウィンドウは次のポイントにジャンプします。 ウィンドウ（chrome、uxterm）をドラッグすると発生するようです。 私が提供できる他のサポート情報を教えてください。 システムログに興味深いものが見つかりません。

これは確認できますが、グラフィックカードが非常に貧弱です...

私も同じ問題を経験しています。 Ubuntu13.10で毎晩ppaから最新のCinnamonを実行しています。

現在、シナモン2.0.2（3x 1920x1080）を使用してarch linuxでマルチヘッドシステムを実行しています。660と7870の両方を試しました。どちらも同じ動作を示し、移動またはサイズ変更時にウィンドウが極端に遅くなります。 オープンソースドライバーのATMを使用しています。 （動作するように更新されたら、Catalystを試します）

私のシステムでは、ほとんど耐えられません。

---更新--- Cinnamon設定パネルで無効にした場合->ウィンドウのタイリングとエッジフリップ->ウィンドウのタイリングとスナップ-ウィンドウは画面上を再び高速で移動します。 私は窓の周りを移動することでこのヒントを得て、その窓を置くことができる位置を示す新しいHUDのものを手に入れました。 HUDが表示されているときはいつでも、ラグが開始されます。

ラップトップでも同じ動作を確認できます。 ManjaroLinuxとCinnamon2.0.6を使用
デュアルコアP6100CPUとIntelHD3000グラフィックカードを持っています。
1.6または1.8では、以前はこの問題は発生していませんでした。
移動中に「ウィンドウコンテンツ」を無効にするMuffinのオプションを探していましたが、Dconfエディターを使用して今のところ運がありません。
なぜこれが起こっているのかを誰かが説明してくれるといいですね。
良い仕事を続けてください;）！

ウィンドウのドラッグの遅延は、ウィンドウのサイズ変更（例：gnome-terminal）と比較して何もありません。数秒かかる場合があります:-(

このバグは、Intel Core I5およびIntelグラフィックコントローラー（第2世代）で確認します。

タイルのHUDしきい値を1に設定すると、タイリングを有効にしたまま、基本的にHUD表示が無効になります。 おそらく次のバージョンでは、HUDをアニメーション化するためのより堅牢なグラフィックのセットとともに、それを無効にするより直接的な方法を追加できます。

このバグは、i7-2600KCPUとAMDR9 290 GPU（最新のベータドライバー）で確認できます。 特に私の120hz画面で。 タイリングとスナップを無効にしても効果はありませんでした。

どのバージョンのCinnamonを実行していますか？ この原因の1つは、比較的最近パッチが適用されました。

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

Cinnamon2.0.14を実行しています。 最新のものをインストールしようとします。

最新のマフィンを持っていることはおそらくもっと重要です。 マフィン2.0.4を使用している場合は、まだ修正されていません。 2.0.5を実行すると、それが実行されます。

（特定の問題が修正されることを保証するものではありません。他の原因が考えられますが、確認する価値があります）

Intel HD4600グラフィックスを搭載したi5-4440sを搭載したMint16のCinnamon2.0.14およびMuffin2.0.5と同様の問題が発生しています。 Windowsをドラッグすると、マウスカーソルに追いつくことができません。 まるで小さな輪ゴムで窓がカーソルに付いているようです。

これが私が経験していることのビデオです。 これは正常な動作ですか？ http://youtu.be/KylzMTZpD7w

このケースは、Cinnamon2.2.14およびDebianJessieのGnomeShell3.12.2でも引き続き有効であることが確認できます。

私もこれを受け取り、正直に言うと本当に気が散ります。 Unityなど、そして実際にWindowsよりも著しくスムーズではありません...

以前に不満を言ったのと同じことを経験しましたが、NVidia GTX760でも問題が発生しました。複数のモニターを使用すると問題はさらに悪化します。

これは、Cinnamon 2.2.14でも、独自のドライバーバージョン340.24（および2台のモニター）を搭載したNVidia GT630で入手できます。 ドライババージョン304にダウングレードすると、ウィンドウは再び高速で移動しますが、その後、ティアリングが発生します。

2014年8月10日日曜日04:04:47 AM EESTに、AndresManzは次のように書いています。

私はこれをCinnamon2.2.14でも入手し、NVidia GT630と
独自のドライバーバージョン340.24（および2つのモニター）。 ダウングレードする場合
ドライババージョン304に移行すると、ウィンドウは再び高速で移動しますが、その後は
涙を体験します。

vsyncがを介して無効にされると、ウィンドウのドラッグラグがなくなります。
環境変数。 AFAIK Nvidiaドライバー304は、によってvsyncを有効にしません
デフォルト（新しいものとは異なり）なので、なぜ速いのかを説明するかもしれません
ダウングレードするときにドラッグして引き裂きます。

ただし、vsyncに関係なく、高いCPU使用率が一般的です。

vsync（Intelドライバー）を有効にしようとしない場合、ウィンドウの遅延がはるかに少ないことを確認できますが、ビデオは視聴できません。

linux mintにこのバグがなく、archlinuxにバグがあるのも奇妙です。

@startasいいえ、

この号に投稿してからさらに奇妙なことに、私は再び問題を抱えていません。 それ以来、いくつかの異なるデバイス、ハードウェア、およびソフトウェア（ディストリビューション）構成にシナモンをインストールしました。

その奇妙な-私はこの問題を「解決」しました（私はインテルHDグラフィックスしか持っていないので、インテルグラフィックスでしか機能しない可能性があります）フラグ「--disable-dri3」でxf86-video-intelを再コンパイルし、同じものでlib32-mesaを再コンパイルしますフラグ「--disable-dri3」。もちろん、フラグ「--enable-dri3」も削除する必要があります。
64ビットLinuxを使用しているときに、dri3なしで64ビットmesaパッケージをコンパイルしてインストールすると、cinnamonデスクトップがクラッシュしますが、64ビットシステム用にxf86-video-intelと32ビットバージョンのmesaのみを再コンパイルすると、「この問題が修正されました」。クロムの巨大なラグを修正しました。
2Dドライバーでdri3を無効にするだけでは機能しませんが、32ビットバージョンのmesaでdri3を無効にしてインストールすることは機能しました。なぜ、このパッケージはデフォルトでインストールされないのでしょうか。64ビットLinuxは64ビットシナモンを使用するため、64ビットを使用します。メサ、そして私はそれがどのように機能したのか分かりません：D

それに関する1つの問題があることを除いて、この問題が最初に作成されたとき、DRI3は存在しませんでした。

現在、archlinuxもデフォルトでDRI3を無効にできると思いますか？

この問題は、Linux（Cinnamonを使用）のKerbal Space Programで見られるものに関連しているように感じます。完璧なフレームワークです。ただし、マウスをクリックして押したままロケットの周りをパンすると、途切れたりジャンプしたりします。 シナモンは、おそらくマウスイベントの再描画ループで何らかのブロッキングを行っていますか？

Arch Linuxでは、xf86-video-intelはdri3なしでコンパイルされますが、mesaはdri3でコンパイルされます。

私の非常に高速なPCでは、シナモンを使用してウィンドウのサイズを変更するのは面倒であり、ウィンドウのコンテンツのリアルタイムの視覚化を無効にするオプションが欲しいです。 xfceはこれを非常に良い方法で行います。

これは起こっていますが、私の外部モニター、Intelグラフィックスを搭載したMacbook（「2014年後半」）でのみ発生しています。 ウィンドウには、外部ディスプレイにのみ、ティアリングアーティファクトも表示されます。 「TearFree」を有効にしてもラグは目立って変化しませんが、ティアリングは修正されます。 xrandrを使用して外部ディスプレイを2x2に拡大しています。

編集：glxgearsのようなものは、そのディスプレイ上でドラッグしてもフレームレートが低下しないことに注意する必要があります。実際、動きが1秒あたり10フレーム未満に見えるにもかかわらず、60Hzモニターで最大71fpsを報告していました。 そのままにしておくと、正常に動作します。

edit2：スケーリングもラグを変更しないようです。

@wrouesnel他...

KSPの問題は、特にRazer DeathAdderなどのゲーミングマウス（私が使用している）を使用している場合は特に、マウスのポーリングレートが高すぎることが原因である可能性があります。 次のチュートリアルが役立つはずです。

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

私が抱えている問題を示すビデオを録画しました（Chromiumブラウザーのドラッグの問題、NemoとFirefoxは比較のためにのみ実行されています）： https ：
IntellJでも同じ問題があり、NemoではPidgin以下の場合もあります。 私はMint17.3とCinnamon2.8.6をamdプロプライエタリドライバーで使用しています。 注意事項：

-ミント17.3とシナモン2.8.6
-オープンソースのGPUドライバーをロードしてテストできなかったため、ソフトウェアレンダリングモードのままになりました（数か月前に17.0 Mintをインストールしたときにxorgオープンソースが正常に機能したことを覚えています）
-amdプロプライエタリCCCで無効なvsyncを強制すると、ウィンドウの遅延が少し少なくなりますが、特にWebサイトのスクロール中に画面が裂けるようになります
-Cinnamonが開始されたばかりのときは、すべてが正常に機能し、ウィンドウのドラッグやサイズの遅延はありません。 この問題はしばらくすると発生します（たとえば、Chromiumが開始されてから10〜40分後）
-Cinnamon（ctrl + alt + esc）を再起動すると、一時的に役立ちます（上記のポイント）
-（編集）：正しく覚えていれば、17.2とCinnamon 2.6では以前は発生しませんでしたが、当時はより大きなティアリングの問題がありました。

編集：
同じことがオープンソースドライバを使用して起こり、なんとかそれらを再インストールしました。

USBスティックから新しいMint17.3 Cinnamonを実行します。これは、上記で説明したのと同じ問題です。
比較のためにUbuntuGnome3とUbuntuMateを確認しました。 両方をUSBからかなり長い間実行している間、問題や速度低下に気づきませんでした。

どういうわけかそれはGPUに関連しているように見えます、特にChromiumのようなGPUをサポートするソフトウェアに起こります。
2つ目の注意点は、メニューバーのインテリハイドを使用し、Chromiumウィンドウでメニューバーをパンチし続けると、より速く発生するように見えることです。 ノートパソコンのファンの声が大きくなり始めるのが聞こえます。 デスクトップ上を循環してChromiumウィンドウをドラッグするのが最適です。

「フルスクリーンウィンドウの作成を無効にする」の有効化/無効化-変更なし

メニューバーをパンチしても再現に時間がかかります。インターネットをしばらく閲覧するのが最も簡単な方法ですが、デバッグには地獄かもしれないと理解しています。

私にもこの問題がありますが、しばらくするとウィンドウが_遅れる_ことに気づきましたが、新しいウィンドウを開いても_ラグ_しません。

たとえば、端末を1時間ほどそこに置いておくと、かなりドラッグしながら途切れますが、新しく開いた端末は問題なく動作します。

そして、はい、それは私がクロームを開いているときです（これは基本的に常に開いています）。

他のすべての側面が正常に機能しているように見えるので、大したことではありません（たとえば、ゲームなどでこれ以上のラグに気付かない）-私が気付いた他の奇妙なことは、ロック画面に約10秒かかることだけです。 ロードする（Mint 17.3にアップグレードする前は気づ​​かなかった）

PS：_laggy_ウィンドウを移動してからしばらくすると、 cinnamon --replaceプロセスで非常に高いCPU使用率（システムでは約16％）が表示されることに気付きました。

インテリハイドを無効にし、パネルを常に表示するように設定します。 現在OSを数時間実行していると驚きます！ 遅れはありません！ 私はただ天国にいるような気がします。

Linux Mint 17.3、Cinnamon 2.8.6、nvidia 352.63独自のドライバーで、カーソルの後ろのウィンドウの遅れを確認できます。 とてもうるさい！ この問題は、合成が有効かどうかとは関係ありません。

Mint 17.3、Cinnamon 2.8.6、i5-4210UまたはnVidea GeForce820Mの統合グラフィックスでもラグを確認できます。
パネルの表示/非表示の設定を少し試してみましたが、パネルが表示されている場合にのみラグが発生しているようです。 自動非表示に設定すると、すべてのウィンドウのドラッグがスムーズになります。
（ええ、これはDarekDeoからのコメントとは正反対です）。

両方のコメントから、パネルに何か問題があるように見えるので、完全に反対ではないかもしれません。 :)

編集：または少なくともそれに関連しています。

私にもこの問題があります。 別のグラフィックドライバを試している人はいますか？ Xubuntu 15.10でこの問題が発生しました。ドライバーを変更すると、すべて正常に機能しました。 私はここでそのオプションを見つけることができないようですか？ 設定パネルでドライバーに移動すると、空白のリストが表示されます。

セットアップ：Fedora 23、Cinnamon、GDM、Nvidia独自のドライバー（Nouveauも使用）

また、ウィンドウをドラッグしたり、Vimでファイルを入力またはスクロールしたりするときに、途切れが発生します。 たとえば、入力している間、キーストロークで数文字が表示され、カーソルが数ミリ秒間ハングし、ハング中に入力した文字がすべて表示されます。

吃音は定期的に発生しているようです。 推測しなければならない場合、約500ミリ秒ごとに言います。 興味深いことに、ウィンドウを一定期間すばやく移動すると、ウィンドウを移動するときにXorgがCPUの大部分（〜53％）を使用することがあります...これは正しくないようです。 何か案は？

編集：Fedora 23 Cinnamon Spin Live CDを起動しましたが、興味深いことに、途切れることはありませんでした。 しかし、HDDのインストールで同じDM環境（Cinnamon、lightdm、nouveauドライバー）を使用しても、引き続き使用できます。 別のマシンのLiveCDから直接Cinnamonスピンをインストールして、問題が解決するかどうかを確認してみてください。 結果を報告します。

うわー、大丈夫。 @DarekDeoに感謝します。これは、スマートパネルが無効になっている場合にはるかにうまく機能します。 ブラウザが全画面表示になっていると、大きなプレーヤーでYouTubeの動画を見ることができないのは残念です。そのため、最初にそのパネルをオンにしましたが、ウィンドウが悪くなりました。

すべてのウィンドウがまだどれだけ遅れているかは奇妙だと思いますが、耐えられないわけではありませんが、Windowsに戻ると、144hzですべてがとてもスムーズに見え、ウィンドウが動き回り、すべてがとてもしっかりしていて安定していると感じます。 Linuxと私の60は、私の144よりもほとんど滑らかに感じられ、ウィンドウをドラッグすると、ウィンドウが遅くなるように感じられます。

また、インテリジェントパネルはウィンドウにも影響を与えるようだと付け加えたいと思います。私のブラウザはグリッチアウトで白くちらつき、いくつか試してみて、もう経験していないものを確認しました。シナモンまたは私のグラフィックドライバで壊れて、パネルが問題だったことがわかりました@ _ @

おもしろいことに、システムモニターアプレットの更新と同じ頻度でスタッターが発生しているように見えたので、パネルから取り外して再起動すると、スタッターがなくなりました。 これは、パネルに何か問題があるかもしれないという@DarekDeoの提案をさらに支持しているようです。 たぶん、更新しているプロセス/ものが何であれ、再描画ループ中に一時的にハングしています（私はグラフィックプログラマーではありません）？

私は実際に同じ問題を抱えています。新しいバージョンのCinnamonにアップデートすると少し良くなりましたが、私のNvidiaデスクトップ（i5-3570k、Nvidia 780ti）は、それほど強力ではないIntelグラフィックスラップトップ（i7-4500u、Intel）ほどスムーズではありません。グラフィックス4400）。

どちらもMint17.3、Cinnamon 3.04（夜間チャネル）、および4.4.0-22カーネルを実行しています。

使用されるドライバーは、NvidiaドライバーPPAのNvidiaの364（364.19-0ubuntu0〜gpu14.04.3）と、カーネルに含まれているIntelドライバーです。

@ davidva-cmlありがとうございます。SytemMonitorアプレットを削除すると、問題が解決しました。

nvidia xserver設定で「synctovblank」をオフにし、Telegramなどのアプリのサイズ変更がバターのようにスムーズになりました

これは私にとってまだ問題です。
私はUbuntu16.04.1の新規インストールを使用しており、ドライバーバージョン375のNvidia GTX 1070を使用しているため、パフォーマンスが問題になることはありません。

@JosephMcc 、この問題をバグとしてマークできますか？

@ davidva-cmlなんとか修正できましたか？ また、ウィンドウをドラッグすると、CPU使用率に加えてXorgが表示されます... Xorgの問題として報告する必要があるかもしれません。 結局のところ、それは常にシナモンの問題である可能性がありますが、再現する最も簡単な方法は、ウィンドウをドラッグしながらバックグラウンドでglxgearsを実行することです。

ただし、この問題の一部の人々は、まったく異なるラグの問題に苦しむ可能性があります（シナモンに関連している可能性があります）。

私は同じ問題を抱えているのではないかと心配しています。 しかし、私は本当に強力なPCを持っています（Core i7-5930K 3.5GHz6コア+最新のnvidiaドライバーを実行するNvidiaTITANX + 32 GBのRAMとOSがSSDにインストールされています）。 したがって、パフォーマンスは問題にはなりません。 しかし、それでも、ウィンドウをドラッグしようとするたびに、このスレッドの他のすべての人と同じように遅くなります。 しかし、私が持っている最もオープンなアプリはそれがより遅いです！
（htop）を監視すると、XorgプロセスがCPU使用率の90％以上を占めていることがわかります。 したがって、シナモンから直接ではなく、Xorgから来る可能性があります。
そこで何が起こっているのかを理解するためのフィードバックがあるのは素晴らしいことです。
ありがとう。

ランニング ：
Linuxカーネル4.10.0-汎用
FerenOS（Linux Mintディストリビューションの最新バージョンを使用しています）
シナモンの実行3.4.6

これが静かになったので、他の人が最近これの回避策を見つけたかどうか私は興味があります。

私にとって、Cinnamonは、このラグが時間の経過とともに再起動から大きくなり、もう取るのがほとんど面倒になるまで不安定になり始めます。通常、画面がスリープから復帰しなくなるため、ハードに再起動する必要があります。 前回の投稿と同様に、これは強力なコンピューター（20コア、40スレッド、デュアルxeon、128 GB RAM、nvidia 1070、デュアルnvme、3x 4kディスプレイ）であるため、パフォーマンスは問題ではなく、他のデスクトップではこれが得られません。 kde以外の環境（独自の合成の問題があります）。 私はvblankと他のほとんどのgl機能をオフにしましたが、通常は1週間以内に不安定になりますが、何かを伝えるためのエラーはありません。

Arch linux、Cinnamon 3.8.1-1、4.16.13カーネル、およびnvidia396.24ドライバーを使用しています。 私はこれがなくなることを期待してアップグレードを続けますが、決してしません。

どうやら（現在のほとんどすべてのデスクトップと同様に）、答えは単にデスクトップのソフトウェアレンダリングを使用することです。 前回は数週間で、約1分ごとに5秒の表示タイムアウトが発生しましたが、時間の経過とともにかなり腹立たしくなりました。

通常、私はpacman -Syyuの後で、別のデスクトップ、KDE（彼らもそれを修正することを祈る）またはMate（marcoは動作する傾向がありますが、デスクトップは他のデスクトップに欠けています）に切り替えますが、今回はシナモンソフトウェアのレンダリングに気づきましたモード。 ソフトウェアレンダリングで通常1週間使用した後、通常は数日後にラグが発生し始めますが、ソフトウェアモードではスムーズであり、デスクトップ使用でのパフォーマンスの低下は実際には見られません。

このコンポジターのバグが続くように見えるのは残念ですが、ほぼ確実にビデオ/ glに関連しています。 コンポジターは私が見つけたすべてのLinuxデスクトップの悩みの種ですが、適切に動作するものはまだ見つかりません。4kで見つけたwindoze aeroでさえ、xps9560に同梱されていた絶対的なくだらないものです。

良い回避策は、/ etc / environmentにCLUTTER_VBLANK=noneを追加し、[Display Configuration]-> [Advanced]のnvidia-settingsですべてのモニターでフォースコンポジションパイプラインを有効にすることです。 これにより、vsync処理がコンポジターからドライバーに移動し、xorg構成でTearFree有効になっているamdgpuでも役立ちます。

そのおかげで、私は/ etc / environmentを設定しましたが、ハードウェアでレンダリングされたバージョンを試す必要はありません。ドラマと混乱を招くだけのようです。 これまでのところ、ソフトウェアでレンダリングされたバージョン、cairo-dockやその他のアプリでの描画の遅延にはかなり満足していますが、ハードウェアバージョンのようにひどくはありません。

興味深いことに、現在ソフトウェアモードでも、同じラグが発生していますが、完全なGPUレンダリングよりもはるかに遅い速度です。 ある種のリソースリークのように感じますが、GPUに対する直接レンダリングでない場合は、デスクトップ内のリソース管理に何らかのバグがあると推測します。

これを修正するのに役立つフィードバック、ログ、デバッグなどは何ですか？ デスクトップがランダム/一般的な間隔でおかしくなりそうなことを除いて、どこにも異常は見られません。

また、明確にするために、これの多くは私がこれを使用している高解像度に関係していると思います。 私のデスクトップは11520x2160（3x 4kディスプレイ）で動作します。これは、GPUアクセラレーションを試行するデスクトップにも負担をかけます。 誰もそのようなことを考慮しているとは思いませんが、4k、5k、そして今では8kが登場しているので、闘争は現実のものです。 これが、ユニティ、kde、シナモン、さらにはこのスケールでgpuに対して直接レンダリングするメイト/マルコを含むすべてのデスクトップで合成が機能しないように見える理由です。

開発者にとっては注意が必要です。コンポジットレンダリングの出現により、Linuxで6x 1080pディスプレイを実行する2010年まで、コンポジットレンダリングの解像度スケールが問題になっています。

そこで、もう一度チェックインします。最近、約80日間の稼働時間の後、ソフトウェア合成でウィンドウの再描画に5秒の遅延が発生した後、再度アップグレードして、何が新しく、うまくいけば改善されたかを確認しました。 短編小説：それほど多くはありません。

現在4.0.7コアシナモンパッケージで、以前のようにソフトウェアレンダリングで起動すると、ウィンドウの一部（特に最小化/終了ボタン）の周りにひどいちらつきと奇妙な更新の問題があり、ひどいものでした。 ハードウェアモードを試してみると、それがなくても動作しますが、ソフトウェアを使用するようになったハードウェアモードの前と同じように、使用後数日で更新ラグが着実に増加し始めました。 これまでのところ、ソフトウェアは4.0のバスケットケースのように見えますが、ハードウェアレンダリングには、数年前からこの問題があります。

これを実際に修正するには何が必要ですか？ ディスプレイの解像度は小さくなっておらず、これらのコンポジターはまだ古いHD解像度を超えるものを処理できないようです。

@mikebutashソフトウェアレンダリングモードは、グラフィックスドライバーのロード中に使用することを意図したものではありませんでした。 VGAモード用です。

4.2用にオープンしているPRの品揃えがあります。 それらをテストすることに抵抗がない場合は、Muffinレポで私のPRブランチをチェックアウトできます。 もう1つのオプションは、[設定]-> [一般]でvsyncを無効にし、nvidia-settingsでフォースコンポジションパイプラインを有効にすることです。 4.0.xシリーズでこれを修正するためにできることは他にありません。

編集：このwikiページも参照して

@jaszhixは、それが解決策になることを意味するのではないことに同意しましたが、特に時間の経過とともに、好ましいハードウェア方法よりもうまく機能することを述べています。 ただし、新しい4.0ではそれほど多くはありませんが、ちらつきと極端なラグを伴う別のリグレッションが発生し、すぐにハードウェアで増分ラグが再び始まりました。 時間の経過とともに悪化するという事実は、コードが不安定であることを示しています。これは3.xの初期から行われており、4.2でもまだ使用されている可能性が高いため、実際にどのバージョンを使用しているかは重要ではありません。

以前は推奨事項に従ってvsyncと強制パイプラインの両方を実行していましたが、nvidia-settingsで強制フルコンポジションパイプラインが再び無効になっていることを確認したので、再度有効にして、その運賃を確認します。 すべてのディスプレイで有効にした後、まだ時折遅れが見られますが、それが傾向として着実に悪化するかどうかはまだわかりません。

すべてのDEが合成に非常に苦労している場合は、大規模な解像度でほとんど同じ問題が発生するため、解像度の大規模な安定性を確保できれば便利です。 私のCinnamonはメモリリークのように機能し、90日ほど後に再起動/アップグレードする前に、cpuの80〜90％をhtopのトップトーカーで使用しているcinnamon-desktopが表示されます（スレッド化されていないようです）私は39の他のスレッドを使用

ほとんどの人は11200x2160の解像度に相当するディスプレイを一般的に実行していませんが、それは3x 4kディスプレイだけであり、毎日より一般的で安価になっている、またはそれに応じて調整されています。 ある時点で、堆肥化は、長期的な安定性を備えたこのような、より大きな解決策を説明するか、大衆により適した妥協の方法を見つける必要があります。 時間の経過とともにウィンドウがぐらついたり透明になったりするのではなく、ウィンドウに安定した再描画が行われます。 何がシステムを不安定にしているのかがわかっていれば、喜んで無効にします。

Nvidiaドライバーのバージョンは何ですか？ あなたは390または396を使用している場合は、上の415.25を使用してUbuntuのPPA 。

モニターの合計解像度は8560x1440であり、現在、PRブランチでCinnamonの速度が低下することはありません。いくつかの期間、開発のためにCinnamonを再起動していません。

強制構成パイプラインは、ある程度の待ち時間を追加します。 通常、この使用はお勧めしません。Cinnamonのvsyncで問題が発生した場合は、nvidia-settingsで「Allowfliping」が有効になっていて、「Synctovblank」が無効になっていることを確認してください。 3.8以降を対象としたドライバーの回避策は使用しないでください。

ラグとは何だと思うかわかりません。ドラッグしたときにカーソルがウィンドウと同期していませんか？ またはウィンドウの一般的な入力レイテンシー？ これらは、コンポジターコードのさまざまな部分の影響を受けます。 https://github.com/linuxmint/muffin/pull/397は両方を改善し、 https：//github.com/linuxmint/muffin/pull/392は後者を改善し

ちらつきと極端な遅れを伴う別の回帰

これらの問題を分けておいてみましょう。ちらつきに関してはすでにいくつかの問題がありますが、4.0でさらに悪化することはありません。 もちろん修正は必要ですが、確実に再現できないものを修正することは困難です。

前回のアップグレードの時点で、私はnvidia 415.25-4を使用しているので、期待の範囲内です。

フリップを許可する（以前は行わなかった）、vblankへの同期を無効にする（通常は行う）、各ディスプレイで完全な合成パイプラインを強制する（今回はチェックをリセットする）を設定しました。

ラグ、私がするすべてのようです。 ウィンドウ間をクリックすると、再描画によって多少の遅延が発生し、画面が所定の位置でフリーズした状態で一度に数秒間停止します。 私は最近、OverlordをSteamでプレイしていて、戦闘中にかなり迷惑をかけています。 私はそれが起こったときに気づき、先制することを学びました。 デスクトップを使用すると、このストールも発生します。これを入力すると、ウィンドウ間および入力中にクリックする際にさまざまなラグ/スタッターが発生します。 入力中、またはマウスやキーボードの操作中に、すべてが1〜2秒間ランダムに停止します。

物をドラッグすると問題が悪化する傾向があります。ほとんどのUIは怒り、デスクトップに遅れをとる傾向があり、視覚的に1、2秒停止します。 90日間早送りすると、ヒットすることを決定したときに行うすべての処理で5秒のストールが発生します。これは数分ごとであり、場合によってはそれより短くなります。

ちらつきに関しては、これがすべてのディスプレイで発生していることに気づきました。ランダムに特定の領域が常に同じであるとは限りませんが、一度に数秒間ちらつき始めて消える過去のある種のゴースト領域のようです。 これは、4kの3つのディスプレイすべてに当てはまり、一度に1つの小さなサブセットになります。

これは、ソフトウェアでのレンダリングのもう1つのアーティファクトのようですが、そうなると奇妙になります。 私はこれをハードウェアレンダリングでは見たことがありませんが、過去90日間ほどそれを使用してソフトウェアで多くのことを行いました。 ソフトウェアに奇妙なことをせずに、ハードウェアの下では十分に悪い。

フリップを許可する（以前は行わなかった）、vblankへの同期を無効にする（通常は行う）、各ディスプレイで完全な合成パイプラインを強制する（今回はチェックをリセットする）を設定しました。

基本的に私が提案したのは、[設定]-> [一般]でマフィンのvsyncを再度有効にし、強制フルコンポジションパイプラインを無効にすることでした。 両方を有効にすると、最も遅延が発生します。

ちらつきは、ソフトウェアレンダリング、およびオンのときに使用される特定のClutterenv変数を使用すると明らかに悪化します。 nomodesetパラメーターを使用して起動したときにこれが発生することはありませんが、Cinnamonがソフトウェアレンダリングを使用しているときにNvidiaドライバーが読み込まれると、ちらつきが発生します。 ＃7985を参照してください。

「ストール」動作は、スレッドが断続的にブロックされているように聞こえます。サードパーティのアプレット/デスクトップ/拡張機能を使用していますか？ gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions確認してください。

正直に言うと、アーチの下にどれだけの痛みがあるのか​​わからない、または通常は落ち込んでいる。 私は彼らのリリースを実行し、アップグレードし、問題がなくなることを少し祈る傾向があります。 ただし、現在はメジャーリビジョン間ではなく、3.xから4.0になりました。 私はあまり逸脱しないようにしています。さまざまなVPN、仮想マシン、その他のさまざまな統合ポイントを含め、このシステムで生計を立てています。

ハードウェアの下でちらつきは発生しませんが、ほとんどすぐにランダムなラグが発生します。 すでに悪化していることがわかります。

ええ、私は再びシナモンの使用をやめなければなりませんでした、ウィンドウの再描画の遅れは数日後に私を殺し、私が積極的に使用していたウィンドウの更新で最大5秒の遅れを取得しました。 これでゲームをしようとすることは不可能です。 通常、ソフトウェアレンダリングに戻ります。ここでは、更新で同じ長い遅延が発生するまでに通常数か月かかりますが、4.0でのソフトウェアレンダリングは完全に使用できなくなりました。

アップビートでは、KDE ​​/ Kwinもバスケットケースであり、ほぼ同じ問題ですが、ウィンドウを最小化して再選択し、変更を加えて再描画する必要があるため、ウィンドウをまったく更新できません。

異なるDEの作曲家がこれを取得するのが本当に難しいのはなぜですか？

私はサードパーティの拡張機能をチェックしましたが、いいえ、私が持っていたのはシナモン拡張機能だけで、ほとんどがデフォルトのものでした。 私は通常、カイロドックをオーバーレイして、カスタムのものに使用しました。

私はhtop、iotop、nvtop、powertopなどを見て、これが発生する理由を見つけるのにかなりの時間を費やしましたが、シナモンデスクトップ以外では、特にリソースピッグとして表示されるものはありません。それ自体、そして時間の経過とともにxorg。

もちろん、これは常にあいまいになる場所です。xorg、nvidiaドライバー、またはシナモンの誤動作はどのくらいですか？ それらを内部でデバッグする良い方法を私は知りません。 問題がないか、特にシナモン自体の内部を監視する良い方法を知っているなら、私は耳を傾けます。それは間違いなく時間の経過とともにリソースを大量に消費するようになるからです。

アプリケーションはその機能を実行しており、「ラグ」の瞬間にウィンドウだけが再描画されないため、何かがブロックされていることに同意しますが、それが何であるかを理解できません。

ラグが最終的にここで多くの悲しみを引き起こしていたので、私はkdeに切り替える必要がありましたが、kdeはチャンピオンのように見えないので、シナモンをもう一度試してみてください。 Mintはほとんど単純すぎて、gnome3、特にubuntuの機能不全バージョンにはあまり耐えられないので、問題が発生してもシナモンに戻ってきます。 明らかに私だけがこのスレッドに参加しているわけではないので、可能であれば修正を手伝いたいです。

私はこれを見て他の人々に何が起こったのか少し興味があります...

異なるDEの作曲家がこれを取得するのが本当に難しいのはなぜですか？

合成の最適化は困難であり、多くの試行錯誤が必要です。 作業するのは簡単なことではありません。

私が持っていたのはシナモンエクステンションだけで、ほとんどがデフォルトのものでした。 私は通常、カイロドックをオーバーレイして、カスタムのものに使用しました。

主に？ どの拡張機能が使用されていますか？ それは重要な詳細です。 合成に関するテキストの壁ではなく、問題の再現に役立つ情報が必要です。 ありがとう！

有効になっているように見えるデスクレットが1つ、天気アプレットbbcwxがありましたが、それが存在する、または以前に実行されている兆候は見られませんでした。

[ user @ host〜] $ gsettingsはorg.cinnamonを有効にします-アプレット
[' 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.cinnamonenabled-desklets
[' [email protected] ：1：50：50']
[ user @ host〜] $ gsettings get org.cinnamon enabled-extensions @ as []

合成を扱うのは複雑な作業であることを私は理解しているので、努力を軽視するつもりはありません。確かにそれらを深く感謝しますが、合成はすべてのDEで行われ、Linuxのすべてで最も弱いリンクを使用します。 Windozeでも、Aeroは、デルのラップトップで箱から出して使用することが限られていることからわかった合成用のバスケットケースになります。 驚くほど多くのユニークな努力がこれを間違えているように見えるので、十分に達成することが不可能に見えるのに、なぜこれがそれほど必要なのか疑問に思います。 より良い方法があるはずです。

ああ、それで、bbcwxが有効になっているがレンダリングされていない場合は、誤動作している可能性があります。 ＃8180のように、パフォーマンスに影響を与える可能性のある4.0.x向けに開いたPRもいくつかあります。 それがいつマージされるかはわかりませんが、誰もがそれを使用するか、GWLに切り替える必要があります。

私は欲求不満を理解しています-それが私がマフィンを改善するためにCを学び始めた理由ですが、オープンPR（私がやってきた）以外にできることはあまりありません。 Linuxのグラフィックスは一般的に長い間遅れをとっており、最近、いくつかの大きな変更（プロトンなど）の後で追いつき始めました。 やるべきことはたくさんあります。私の目標は、Windows10のDWMと同じくらい応答性の高いマフィンを作成することです。

有効にしたことすら覚えていないので、ランダムで忘れられていたに違いありません。 方法がわかれば削除します。

私は2006年からフルタイムでLinuxを使用しており、合成の前後を覚えています。以前は生活がずっと楽でした。 それが始まったとき、私は何年もの間UbuntuとCompizの問題に取り組んでいました。

これまでのところ、3.xから4.0への移行はCinnamonで最悪でしたが、kwin、compiz、mutterはすべて、時間の経過とともに悪化する固有のリソースリークに苦しんでいるようです。 それらはすべてそれを行うので、すべてのDEの間で不安定化を引き起こしているのは、xorgやnvidiaドライバーなどの低レベルのコンポーネントであると私はよく思いますが、実際にはわかりません。 したがって、私はDEから始めますが、これらのグラフィック遅延の原因を突き止めるためにさまざまな* topも監視していますが、これまでのところ役に立ちません。

私はarchの通常のpacmanアップグレードに従って、その外側の更新をきれいにプルしようとする傾向があります。archで次のマフィンリリースを試す方法がわかりません。

私もこの問題を抱えています。 私の仕様についてはスクリーンショットを参照してください。 私も128GBのRAMを持っています： https ：

XFCEへの移行を解決> <（シナモンでは解決されない）

@zenfulcoderあなたが128GBのRAMを使用するh * Kはどこですか？ たぶんあなたがあなたの場合には確かにXFCEに移動する時です..ハハ

@ danger89ええ私はXFCEが大好きです、私はXFCEの年の後にシナモンに切り替えました。 現代のデスクトップとその統合のためにCinnamonが好きでした。 OpenGLを実行する必要があるのは残念です。

私のボードはそれをサポートしていたので、XDに入れました。 しかし、そうすれば、仕事のために、私は決して尽きることはありません。 基本的に無制限。 しかし、それでもシナモンでは遅くなります!!

@zenfulcoderボトルネックがどこにある

それでも、上記のセクションでわかるように、仕様とはまったく関係がない可能性があります。 ビデオドライバー、Xorg、またはその領域の何かにいくつかのバグがあります。

@ danger89それは間違いなくシナモンの問題です。 私はv4の方が良いかもしれないと読みましたが、Debianにとってはまだ十分に安定していません。