Cinnamon: Verzögerung beim Neuzeichnen von Fenstern beim Ziehen von Fenstern

Ich hasse es, "ich auch" zu sagen, aber ... "ich auch!" Ich laufe auf einer etwas älteren Box, wobei Cinnamon auf Ubuntu 13.04 läuft. Alles andere scheint in Ordnung zu sein, es ist nur das Ziehen von Fenstern, das ein Problem darstellt. Und das "Stottern" macht sich bemerkbar, wonach das Fenster einfach zum nächsten Punkt springt. Es scheint beim Ziehen eines Fensters (Chrome, Uxterm) zu passieren. Lassen Sie mich wissen, welche weiteren unterstützenden Informationen ich bereitstellen kann. Ich kann in meinen Systemprotokollen nichts Interessantes finden.

Ich kann das bestätigen, aber ich habe eine sehr schlechte Grafikkarte ...

Ich habe auch die gleichen Probleme. Ich verwende den neuesten Cinnamon vom nächtlichen ppa unter Ubuntu 13.10.

Ich verwende derzeit ein Multihead-System unter Arch Linux mit Cinnamon 2.0.2 (3x 1920x1080). Ich habe sowohl einen 660 als auch meinen 7870 ausprobiert. Beide weisen das gleiche Verhalten auf, extrem verzögerte Fenster beim Verschieben oder Bemessen. Ich benutze die OpenSource-Treiber atm. (Wird versuchen, Katalysator, sobald sie auf Arbeit aktualisiert werden)

Auf meinem System ist es fast unerträglich.

--- Update --- Wenn ich im Fenster "Zimteinstellungen" deaktiviere -> Fensterkacheln und Kanten spiegeln -> Fensterkacheln und Fangen - bewegen sich die Fenster wieder schnell über den Bildschirm. Ich bekam diesen Hinweis, indem ich mich um ein Fenster bewegte, und ich bekam das neue HUD-Ding, das mir die Position zeigte, an der ich dieses Fenster platzieren konnte; Wann immer HUD auftauchte, startet der Lagg.

Ich kann das gleiche Verhalten auf meinem Laptop bestätigen. mit Manjaro Linux und Cinnamon 2.0.6
Ich habe eine Dual-Core-P6100-CPU und eine Intel HD 3000-Grafikkarte.
Ich habe dieses Problem noch nie mit 1.6 oder 1.8.
Ich suchte mit Muffin nach einer Option, um "Fensterinhalte" während des Verschiebens zu deaktivieren, aber bisher kein Glück mit dem Dconf-Editor.
Es wäre großartig, wenn jemand eine Erklärung liefern würde, warum dies geschieht.
Mach weiter so ;)!

Die Verzögerung beim Ziehen von Fenstern ist nichts im Vergleich zur Größenänderung von Fenstern (z. B. Gnome-Terminal). Sie kann einige Sekunden dauern :-(

Ich bestätige diesen Fehler mit Intel Core I5 ​​und Intel Grafikcontroller (2. Generation).

Sie können den HUD-Schwellenwert für Kacheln auf 1 setzen. Dadurch wird die HUD-Anzeige im Wesentlichen deaktiviert, während die Kacheln weiterhin aktiviert bleiben. Möglicherweise kann in der nächsten Version eine direktere Möglichkeit zum Deaktivieren hinzugefügt werden, zusammen mit einem robusteren Satz von Grafiken zum Animieren des HUD.

Ich kann diesen Fehler auf der i7-2600K-CPU und der AMD R9 290-GPU (neueste Betatreiber) bestätigen. Besonders auf meinem 120Hz Bildschirm. Das Deaktivieren von Kacheln und Einrasten hat nicht geholfen.

Welche Version von Cinnamon verwenden Sie? Eine Ursache hierfür wurde vor relativ kurzer Zeit behoben.

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

Ich verwende Cinnamon 2.0.14. Wird versuchen, die neueste zu installieren.

Das neueste Muffin zu haben ist wahrscheinlich wichtiger. Wenn Sie auf Muffin 2.0.4 sind, haben Sie das Update noch nicht. Wenn Sie 2.0.5 ausführen, wird es vorhanden sein.

(Ich garantiere nicht, dass Ihr spezielles Problem behoben ist, könnte möglicherweise eine andere Ursache sein, aber es lohnt sich zu überprüfen)

Ich erlebe etwas Ähnliches mit Cinnamon 2.0.14 und Muffin 2.0.5 auf Mint 16 mit einem i5-4440s mit Intel HD 4600-Grafik. Wenn ich Windows ziehe, können sie nicht mit dem Mauszeiger mithalten. Es ist, als ob die Fenster mit einem kleinen Gummiband an meinem Cursor befestigt sind.

Hier ist ein Video von dem, was ich erlebe. Ist das normal? http://youtu.be/KylzMTZpD7w

Ich kann bestätigen, dass dieser Fall weiterhin für Cinnamon 2.2.14 und auch für Gnome Shell 3.12.2 auf Debian Jessie gültig ist.

Ich verstehe das auch und es ist wirklich ablenkend, um ehrlich zu sein. Deutlich weniger flüssig als Unity usw. und tatsächlich Windows ...

Ich habe das gleiche erlebt, worüber ich mich zuvor beschwert habe, aber auch mit einer NVidia GTX 760. Das Problem ist definitiv schlimmer mit mehreren Monitoren.

Ich bekomme dies auch auf Cinnamon 2.2.14 mit einem NVidia GT 630 mit der proprietären Treiberversion 340.24 (und zwei Monitoren). Beim Downgrade auf die Treiberversion 304 bewegen sich die Fenster wieder schnell, aber dann tritt ein Riss auf.

Am Sonntag, den 10. August 2014 um 04:04:47 Uhr EEST schrieb Andres Manz:

Ich bekomme das auch auf Cinnamon 2.2.14 mit einem NVidia GT 630 mit dem
proprietäre Treiberversion 340.24 (und zwei Monitore). Beim Downgrade
zur treiberversion 304 bewegen sich die fenster wieder schnell, aber dann ich
Erfahrung reißen.

Die Verzögerung beim Ziehen des Fensters verschwindet, wenn der vsync über das deaktiviert wird
Umgebungsvariablen. Der AFAIK Nvidia-Treiber 304 aktiviert vsync by nicht
Standard (im Gegensatz zu den neueren), so kann es erklären, warum Sie schnell haben
Ziehen und Zerreißen, wenn Sie ein Downgrade durchführen.

Unabhängig von vsync ist jedoch eine hohe CPU-Auslastung weit verbreitet.

Kann bestätigen, dass Windows viel weniger verzögert ist, wenn ich nicht versuche, vsync (Intel-Treiber) zu aktivieren, aber dann sind Videos nicht beobachtbar.

Es ist auch seltsam, dass Linux Mint diesen Fehler nicht hat und Arch Linux.

@startas Nein, ich bekomme es auf Mint 17.

Noch seltsamer, seit ich in dieser Ausgabe gepostet habe, hatte ich das Problem nicht mehr. Ich habe seitdem Zimt auf verschiedenen Geräten, Hardware- und Softwarekonfigurationen (Distributionen) installiert.

Es ist seltsam - ich habe dieses Problem "gelöst" (ich habe nur Intel HD-Grafiken, daher funktioniert es möglicherweise nur für Intel-Grafiken), indem ich xf86-video-Intel mit dem Flag "--disable-dri3" neu kompiliert und lib32-mesa mit demselben neu kompiliert habe flag "--disable-dri3", natürlich musst du auch flag "--enable-dri3" entfernen.
Während ich 64-Bit-Linux verwende, stürzt das Kompilieren des 64-Bit-Mesa-Pakets ohne dri3 und das Installieren des Cinnamon-Desktops ab, aber irgendwie hat das Neukompilieren nur von xf86-Video-Intel und der 32-Bit-Version von Mesa für 64-Bit-Systeme dieses Problem "behoben" große Verzögerungen in Chrom behoben.
Nur das Deaktivieren von dri3 in 2D-Treibern funktioniert nicht, aber das Deaktivieren von dri3 in der 32-Bit-Version von mesa und die Installation haben funktioniert. Ich frage mich, warum - dieses Paket ist nicht einmal standardmäßig installiert, da 64-Bit-Linux 64-Bit-Zimt verwendet, also 64-Bit Mesa, und ich habe keine Ahnung, wie es funktioniert hat: D.

außer es gibt ein Problem damit, DRI3 existierte nicht, als dieses Problem zum ersten Mal erstellt wurde.

Derzeit deaktiviert Arch Linux auch DRI3 standardmäßig, denke ich?

Dieses Problem scheint mit etwas zu tun zu haben, das ich im Kerbal Space Program unter Linux (mit Cinnamon) sehe: perfekte Frameworks, außer wenn ich mit der Maus klicke und halte, um eine Rakete zu schwenken - dann stottert und springt es schlecht. Cinnamon blockiert möglicherweise die Redraw-Schleife für Mausereignisse?

Unter arch linux wird xf86-video-intel ohne dri3 kompiliert, mesa jedoch mit dri3.

Auf meinem recht schnellen PC ist das Ändern der Fenstergröße mit Zimt ein Problem, und ich würde gerne eine Option zum Deaktivieren der Echtzeitvisualisierung des Fensterinhalts verwenden. xfce macht das sehr gut.

Dies geschieht jedoch nur auf meinem externen Monitor, auf einem Macbook ("Ende 2014") mit Intel-Grafik. Das Fenster zeigt auch reißende Artefakte an, wiederum nur auf dem externen Display. Die Verzögerung ändert sich nicht merklich, wenn ich "TearFree" aktiviere, aber es behebt das Reißen. Ich skaliere das externe Display mit xrandr 2x2.

Bearbeiten: Ich sollte beachten, dass so etwas wie glxgears keine verringerte Bildrate aufweist, wenn ich es auf diesem Display herumziehe. Tatsächlich wurden auf einem 60-Hz-Monitor ~ 71 fps gemeldet, obwohl die Bewegung <10 Bilder pro Sekunde aussehen lässt. Wenn Sie es in Ruhe lassen, funktioniert es normal.

edit2: Es scheint, dass die Skalierung auch die Verzögerung nicht ändert.

@wrouesnel und andere ...

Das KSP-Problem ist wahrscheinlich speziell darauf zurückzuführen, dass Ihre Mausabfragerate zu hoch eingestellt ist, insbesondere wenn Sie eine Gaming-Maus wie einen Razer DeathAdder oder einen ähnlichen (den ich verwende) haben. Das folgende Tutorial soll helfen:

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

Ich habe ein Video aufgenommen, das ein Problem zeigt, das ich habe (Problem beim Ziehen des Chromium-Browsers, während Nemo und Firefox nur zum Vergleich ausgeführt werden): https://youtu.be/Ec99EYjwiqY
Ich habe das gleiche Problem mit IntellJ und manchmal mit Pidgin oder seltener mit Nemo. Ich benutze Mint 17.3 und Cinnamon 2.8.6 mit und proprietären Treibern. Dinge zu beachten:

-Mint 17.3 mit Zimt 2.8.6
- OpenSource-GPU-Treiber konnten nicht geladen werden, um sie zu testen. Dadurch wurde ich jetzt im Software-Rendering-Modus gehalten (ich erinnere mich, dass xorg Open Source einwandfrei funktioniert hat, als ich vor einigen Monaten 17.0 Mint installiert habe).
- Das Erzwingen von deaktiviertem vsync in amd propietary CCC hilft etwas weniger verzögerten Fenstern, aber es macht das Zerreißen des Bildschirms besonders beim Scrollen von Websites
-Wenn Cinnamon gerade angefangen hat, funktioniert alles einwandfrei, kein verzögertes Ziehen von Fenstern, keine verzögerte Größenänderung. Das Problem tritt nach einiger Zeit auf (z. B. 10 bis 40 Minuten nach dem Start von Chromium).
- Ein Neustart von Cinnamon (Strg + Alt + Esc) hilft vorübergehend (über Punkt)
- (Bearbeiten): Es ist nicht vor 17.2 und Cinnamon 2.6 passiert, wenn ich mich richtig erinnere, aber ich hatte damals ein größeres Reißproblem.

Bearbeiten:
Dasselbe passiert mit OpenSource-Treibern, die neu installiert werden konnten.

Ausführen von frischem Mint 17.3 Cinnamon vom USB-Stick, das gleiche Problem wie oben erläutert.
Zum Vergleich Ubuntu Gnome3 und Ubuntu Mate überprüft. Während ich beide ziemlich lange über USB laufen ließ, habe ich keine Probleme / Verlangsamungen bemerkt.

Irgendwie sieht es so aus, als ob es mit der GPU zusammenhängt, besonders mit Software, die GPU-Unterstützung bietet, wie Chromium.
Das zweite, was zu beachten ist, ist, dass es so aussieht, als ob es schneller geht, wenn Sie die Menüleiste intelihide haben und weiterhin die Menüleiste mit dem Chromium-Fenster stanzen. Ich kann hören, wie Fans im Laptop lauter arbeiten. Ziehen Sie das Chromium-Fenster am besten, indem Sie es über den Desktop verteilen.

"Komponieren für Vollbildfenster deaktivieren" aktiviert / deaktiviert - keine Änderung

Es ist langsam, sich selbst mit der Punching-Menüleiste neu zu formulieren. Der einfachste Weg ist, einfach einige Zeit im Internet zu surfen, aber ich verstehe, dass es die Hölle zum Debuggen sein könnte.

Ich habe auch dieses Problem - aber was mir aufgefallen ist, dass Fenster nach einiger Zeit _laggy_ werden - aber wenn ich neue öffne, _lag_ sie nicht.

Wenn ich zum Beispiel ein Terminal etwa eine Stunde lang dort sitzen lasse, stottert es beim Ziehen, aber ein neu geöffnetes Terminal verhält sich einwandfrei.

Und ja, dann habe ich Chrom offen (was im Grunde die ganze Zeit offen ist).

Es ist keine große Sache, da jeder andere Aspekt gut zu funktionieren scheint (zum Beispiel merkt man keine größere Verzögerung bei Spielen oder so) - das einzige andere seltsame, was mir aufgefallen ist, ist, dass der Sperrbildschirm ungefähr 10 Sekunden dauert. zu laden (ich habe das nie bemerkt, bevor ich auf Mint 17.3 ugraded habe)

PS: Ich habe festgestellt, dass der cinnamon --replace -Prozess einige Zeit nach dem Verschieben eines _laggy_-Fensters eine recht hohe CPU-Auslastung aufweist (ca. 16% auf meinem System).

Deaktiviert Intellihide, Panel so einstellen, dass immer angezeigt wird. Läuft derzeit Betriebssystem für einige Stunden und Überraschung! keine Verzögerungen! Ich fühle mich einfach wie im Himmel.

Ich kann die Verzögerung des Fensters hinter dem Cursor in Linux Mint 17.3, Cinnamon 2.8.6, mit dem proprietären Treiber nvidia 352.63 bestätigen. Sehr nervig! Das Problem ist unabhängig davon, ob Compositing aktiviert ist oder nicht!

Ich kann die Verzögerung auch mit Mint 17.3, Cinnamon 2.8.6 und integrierten Grafiken von i5-4210U oder einer nVidea GeForce 820M bestätigen.
Ich habe ein wenig mit den Einstellungen für das Ein- / Ausblenden des Bedienfelds gespielt und es scheint, dass die Verzögerung nur vorhanden ist, wenn das Bedienfeld angezeigt wird. Wenn ich es so einstelle, dass es automatisch ausgeblendet wird, sind alle Fensterzüge glatt.
(Ja, ich weiß, dass dies das genaue Gegenteil des Kommentars von DarekDeo ist).

Vielleicht nicht ganz im Gegenteil, aus unseren beiden Kommentaren geht hervor, dass etwas mit dem Panel nicht stimmt. :) :)

bearbeiten: oder zumindest damit verbunden.

Ich habe auch dieses Problem. Hat jemand einen anderen Grafiktreiber ausprobiert? Ich hatte dieses Problem unter Xubuntu 15.10 und als ich den Treiber wechselte, funktionierte alles einwandfrei. Ich kann diese Option hier nicht finden? Ich gehe zu den Treibern im Einstellungsfeld und eine leere Liste wird angezeigt.

Setup: Fedora 23, Cinnamon, GDM, Nvidia-eigene Treiber (auch mit Nouveau)

Ich habe auch ein Stottern beim Ziehen von Fenstern und beim Tippen oder Scrollen durch eine Datei in Vim. Während ich tippe, erscheinen beispielsweise einige Buchstaben mit dem Tastenanschlag, dann bleibt der Cursor einige Millisekunden lang hängen, und dann erscheinen alle Buchstaben, die ich während des Hängens eingegeben habe.

Das Stottern scheint regelmäßig zu passieren. Wenn ich raten müsste, würde ich ungefähr alle 500 ms sagen. Interessanterweise zeigt Xorg, wenn ich ein Fenster für einen bestimmten Zeitraum schnell bewege, dass Xorg beim Verschieben von Fenstern manchmal einen großen Prozentsatz der CPU (~ 53%) beansprucht ... dies scheint nicht richtig zu sein. Irgendwelche Ideen?

EDIT: Ich habe die Fedora 23 Cinnamon Spin Live CD hochgefahren und bin interessanterweise auf kein Stottern gestoßen. Die Verwendung derselben DM-Umgebung (Cinnamon-, LightDM- und Nouveau-Treiber) in meiner Festplatteninstallation funktioniert jedoch weiterhin. Ich kann versuchen, den Cinnamon-Spin direkt von der Live-CD auf einem anderen Computer zu installieren, um festzustellen, ob das Problem weiterhin besteht. Ich werde mit allen Ergebnissen berichten.

Wow, okay. Dank @DarekDeo funktioniert dies viel besser, wenn das Smart Panel deaktiviert ist. Nur schade, dass ich im großen Player keine Youtube-Videos ansehen kann, wenn mein Browser jetzt im Vollbildmodus angezeigt wird. Deshalb habe ich das Bedienfeld zuerst aktiviert, aber die Fenster wurden schlecht.

Ich finde es seltsam, wie träge alle Fenster noch sind, sie sind nicht unerträglich, aber wenn ich zu Windows zurückkehre, lässt mein 144 Hz alles so glatt aussehen und sich so glatt anfühlen, Fenster bewegen und sie fühlen sich alle so solide und stabil an Linux und meine 60 fühlen sich fast flüssiger an als meine 144 und Windows fühlen sich an, als wären sie nachlässig, wenn Sie sie herumschleppen.

Ich möchte auch nur hinzufügen, dass das intelligente Bedienfeld auch Fenster zu beeinflussen scheint. Mein Browser flackerte weiß, als er viel ausfiel, und ging ein paar Mal durch, um herauszufinden, welcher es nicht mehr erlebte, dachte, etwas könnte sein gebrochen mit Zimt oder meinem Grafiktreiber, stellte sich heraus, dass das Panel das Problem war @ _ @

Nun, das ist interessant. Ich bemerkte, dass das Stottern, das ich sah, mit der gleichen Häufigkeit auftrat, mit der das System Monitor-Applet aktualisiert wurde. Deshalb habe ich es aus dem Bedienfeld entfernt und neu gestartet. Jetzt ist das Stottern für mich verschwunden. Dies scheint @DarekDeos Vorschlag, dass etwas mit dem Panel nicht stimmt, weiter zu unterstützen. Vielleicht hängt der Prozess / die Sache, die gerade aktualisiert wird, während der Neuzeichnungsschleife kurz (ich bin kein Grafikprogrammierer)?

Ich habe das gleiche Problem, das Update auf eine neuere Version von Cinnamon hat es ein bisschen besser gemacht, aber mein Nvidia-Desktop (i5-3570k, Nvidia 780ti) ist immer noch nicht so flüssig wie mein viel weniger leistungsfähiger Intel-Grafik-Laptop (i7-4500u, Intel) Grafik 4400).

Beide verwenden Mint 17.3, Cinnamon 3.04 (nächtlicher Kanal) und den Kernel 4.4.0-22.

Die verwendeten Treiber sind Nvidias 364 (364.19-0ubuntu0 ~ gpu14.04.3) von den Nvidia-Treibern PPA und die im Kernel enthaltenen Intel-Treiber.

@ davidva-cml danke, das Entfernen des Sytem Monitor-Applets hat das Problem für mich gelöst!

Das Deaktivieren von "Mit vblank synchronisieren" in den nvidia xserver-Einstellungen und das Ändern der Größe von Apps wie "Telegramm" ist jetzt butterweich

Das ist immer noch ein Problem für mich.
Ich verwende eine Neuinstallation von Ubuntu 16.04.1 mit einer Nvidia GTX 1070 mit Treiberversion 375, daher sollte die Leistung kein Problem darstellen.

@JosephMcc , können wir dieses Problem als Fehler markieren?

@ davidva-cml Hast du es geschafft, es zu reparieren? Ich sehe Xorg auch zusätzlich zur CPU-Auslastung beim Ziehen von Fenstern ... Vielleicht sollten wir es als Xorg-Problem melden. Obwohl es immer ein Zimtproblem sein könnte. Die einfachste Möglichkeit zur Reproduktion besteht darin, glxgears im Hintergrund auszuführen, während Sie Fenster herumziehen.

Einige Personen in diesem Problem können jedoch unter einem völlig anderen Lagg-Problem leiden (das möglicherweise mit Zimt zusammenhängt).

Ich fürchte, ich habe das gleiche Problem. Aber ich habe einen wirklich leistungsstarken PC (Core i7-5930K 3,5 GHz 6 Kerne + Nvidia TITAN X mit dem neuesten NVIDIA-Treiber + 32 GB RAM und meinen auf einer SSD installierten Betriebssystem-Ins). Aufführungen sollten also kein Thema sein. Aber jedes Mal, wenn ich versuche, ein Fenster zu ziehen, bin ich langsam wie alle anderen in diesem Thread. Aber die offensten Apps, die ich habe, sind langsamer!
Wenn ich (htop) überwache, kann ich sehen, dass der Xorg-Prozess 90% oder mehr der CPU-Auslastung beansprucht. Es könnte also von Xorg kommen, nicht direkt von Zimt.
Es sollte toll sein, Feedback zu haben, um zu verstehen, was dort vor sich geht.
Vielen Dank.

Laufen :
Linux Kernel 4.10.0-generic
FerenOS (das die neueste Version der Linux Mint Distribution verwendet)
Zimt laufen lassen 3.4.6

Ich bin neugierig, ob andere in letzter Zeit irgendwelche Umgehungsmöglichkeiten dafür gefunden haben, da dies ruhig geworden ist.

Für mich beginnt Cinnamon mit der Destabilisierung, wobei diese Verzögerung vom Neustart mit der Zeit zunimmt, bis es fast zu nervig wird, um es länger zu dauern, und normalerweise muss ich es schwer neu starten, da der Bildschirm nicht mehr aus dem Ruhezustand aufwacht. Wie im letzten Beitrag handelt es sich um einen leistungsstarken Computer (20 Kerne, 40 Threads, Dual XEON, 128 GB RAM, NVIDIA 1070, Dual NVME, 3x 4K-Displays), sodass die Leistung kein Problem darstellt und ich dies bei anderen Desktops nicht verstehe andere Umgebungen als kde (die ihre eigenen Compositing-Probleme haben). Ich habe vblank und die meisten anderen gl-Funktionen deaktiviert und destabilisiere mich immer noch, normalerweise innerhalb einer Woche, aber niemals irgendwelche Fehler, um etwas zu verraten.

Ich verwende Treiber für Arch Linux, Cinnamon 3.8.1-1, 4.16.13 Kernel und NVIDIA 396.24. Ich aktualisiere weiter in der Hoffnung, dass dies verschwindet, aber nie.

Anscheinend (wie bei fast jedem Desktop jetzt) ​​besteht die Antwort darin, einfach das Software-Rendering des Desktops zu verwenden. Ich habe es letztes Mal ein paar Wochen geschafft, bevor ich ungefähr jede Minute ein Zeitlimit von 5 Sekunden bekam, was mit der Zeit ziemlich ärgerlich wird.

Normalerweise wechsle ich nach einem Pacman-Syyu einfach zu einem anderen Desktop, KDE (betend, dass sie es auch reparieren) oder Mate (Marco neigt dazu, sich zu verhalten, aber der Desktop fehlt ansonsten im Vergleich zu anderen), aber diesmal bemerkte ich das Rendern der Zimtsoftware Modus. Nach einer Woche normalen Gebrauchs mit Software-Rendering würde ich normalerweise nach ein paar Tagen anfangen, die Verzögerung zu bekommen, aber im Software-Modus war es reibungslos und es gibt wirklich keinen Nachteil bei der Leistung bei der Desktop-Nutzung.

Es ist eine Schande, dass dieser Compositor-Fehler weiterhin besteht, aber mit ziemlicher Sicherheit mit Video / Gl zusammenhängt. Compositors sind der Fluch jedes Linux-Desktops, den ich finde. Ich habe noch keinen gefunden, der sich richtig verhält. Selbst Windoze Aero, das ich in 4k gefunden habe, ist absoluter Mist, der mit meinem xps 9560 geliefert wurde.

Eine gute Problemumgehung besteht darin, / etc / environment CLUTTER_VBLANK=none hinzuzufügen und die Force Composition Pipeline auf allen Monitoren in den NVIDIA-Einstellungen unter Anzeigekonfiguration -> Erweitert zu aktivieren. Dies verschiebt die vsync-Behandlung vom Compositor zum Treiber und hilft auch bei amdgpu, wenn TearFree in der xorg-Konfiguration aktiviert ist.

Vielen Dank dafür, ich habe in meiner / etc / -Umgebung festgelegt, aber ich habe keine Notwendigkeit gefunden, die Hardware-gerenderte Version auszuprobieren, da sie nur Drama und Chaos einzuladen scheint. Ich bin ziemlich zufrieden mit der Software-gerenderten Version, einigen Verzögerungen beim Zeichnen im Cairo-Dock und einigen anderen Apps, aber nicht so sehr mit der Hardware-Version, die auf sich selbst kackt.

Interessant, selbst im Softwaremodus entwickle ich die gleiche Verzögerung, aber mit einer viel langsameren Geschwindigkeit als beim vollständigen GPU-Rendering. Es fühlt sich wie eine Art Ressourcenleck an, aber wenn nicht direktes Rendern gegen die GPU, gehe ich von einem Fehler in der Ressourcenverwaltung auf dem Desktop aus.

Was sind nützliche Rückmeldungen, Protokolle, Debugs usw., um dies zu beheben? Ich sehe nirgendwo etwas Ungewöhnliches, außer dass der Desktop in zufälligen / gemeinsamen Intervallen ausflippt.

Ich denke auch, dass dies viel mit den hohen Auflösungen zu tun hat, bei denen ich dies verwende. Mein Desktop läuft mit 11520x2160 (3x 4k-Displays), wodurch jeder Desktop, den ich finde, der sogar die GPU-Beschleunigung versucht, besteuert wird. Ich glaube nicht, dass irgendjemand so etwas berücksichtigt, aber mit 4k, 5k und jetzt 8k ist der Kampf real. Aus diesem Grund scheint Compositing unter jedem Desktop zu brechen, einschließlich Unity, Kde, Zimt oder sogar Mate / Marco, mit direktem Rendern gegen GPU in dieser Größenordnung.

Dies ist etwas, das die Entwickler beachten sollten. Die Auflösungsskala für das ordnungsgemäße Rendern von Composites ist seit ~ 2010 ein Problem, als ich mit dem Aufkommen des Compositing 6x 1080p-Displays unter Linux ausführte.

Nachdem ich 5 Sekunden Verzögerung beim Neuzeichnen von Fenstern unter Software Compositing festgestellt habe, habe ich nach etwa 80 Tagen Betriebszeit erneut ein Upgrade durchgeführt, um zu sehen, was neu und hoffentlich verbessert ist. Lange Rede, kurzer Sinn: nicht so sehr.

Jetzt bei 4.0.7 Kern-Zimt-Paketen und das Starten mit Software-Rendering wie zuvor war miserabel mit schrecklichen Flackern und seltsamen Aktualisierungsproblemen um Teile der Fenster (dh insbesondere die Minimierungs- / Beenden-Schaltflächen). Wenn ich den Hardwaremodus versuche, funktioniert es ohne das, aber fast sofort bekam ich innerhalb weniger Tage nach der Verwendung eine Aktualisierungsverzögerung, die stetig zunimmt, wie zuvor im Hardwaremodus, der mich dazu veranlasste, Software zu verwenden. Software scheint in 4.0 bislang ein Korb zu sein, aber beim Hardware-Rendering tritt dieses Problem noch seit Jahren auf.

Was könnte nötig sein, um dies tatsächlich zu beheben? Die Auflösungen in Displays werden nicht kleiner, und diese Compositors scheinen immer noch nichts anderes als alte HD-Auflösungen zu verarbeiten.

@mikebutash Der Software-Rendering-Modus sollte niemals verwendet werden, während der Grafiktreiber geladen ist. Es ist für den VGA-Modus.

Es gibt eine Auswahl an PRs, die für 4.2 geöffnet sind. Wenn Sie sie gerne testen möchten, können Sie meine PR-Filialen auf dem Muffin-Repo überprüfen. Die andere Option wäre das Deaktivieren von vsync unter Einstellungen -> Allgemein und das Aktivieren der Force Composition Pipeline in den NVIDIA-Einstellungen. Es kann nichts anderes getan werden, um dies für die 4.0.x-Serie zu beheben.

Bearbeiten: Siehe auch diese Wiki-Seite .

@jaszhix , stimmte zu, dass es keine Lösung sein soll, sagt aber etwas, dass es besser funktioniert als die bevorzugte Hardwaremethode, insbesondere im Laufe der Zeit. Nicht so sehr auf neuerem 4.0, aber eine weitere Regression mit dem Flackern und der extremen Verzögerung, und sofort hat die inkrementelle Verzögerung auf der Hardware wieder begonnen. Die Tatsache, dass es mit der Zeit immer schlimmer wird, zeigt, dass der Code instabil ist, was seit Anfang 3.x und wahrscheinlich immer noch in Ihrem 4.2-System der Fall ist. Ich bezweifle, dass es wichtig ist, auf welcher Version ich mich tatsächlich befinde.

Ich hatte zuvor sowohl vsync als auch Forced Pipeline gemäß Empfehlung durchgeführt, habe jedoch festgestellt, dass die Force Full Composition-Pipeline in den NVIDIA-Einstellungen wieder deaktiviert wurde. Ich sehe bereits immer noch eine gelegentliche Verzögerung, nachdem ich es auf allen Displays aktiviert habe, aber es bleibt abzuwarten, ob es stetig schlechter wird, wenn es dazu neigt.

Wenn alle DEs so sehr auf Compositing aus sind, wäre es schön, wenn sie eine stabile Auflösung gewährleisten würden, da sie bei großen Auflösungen meistens dieselben Probleme haben. Zimt auf meinem wirkt wie ein Speicherverlust, vor dem Neustart / Upgrade nach etwa 90 Tagen würde ich sehen, dass Zimt-Desktop üblicherweise 80-90% einer CPU in einem Top-Talker in htop verwendet (schien nicht zu fädeln) Gut im Kern, da ich 39 andere Threads habe, die es verwenden könnte ) und viel Speicher verwendet, etwa 20-30 GB (etwas zu sagen, mit 128 GB in diesem System). Es muss einen Weg geben, dies im Maßstab zu testen, und es scheint eine Art valgridähnlicher Stresstest zu geben. Nach ungefähr 90 Tagen ist Zimt immer bereit zu platzen, und das ist in Software-Rendering. Es wird normalerweise innerhalb einer Woche in Hardware sterben. KDE leidet ähnlich.

Die meisten Leute verwenden normalerweise keine Displays mit einer Auflösung von 11200 x 2160, aber das sind nur 3 x 4k-Displays, die von Tag zu Tag häufiger und billiger werden, oder passen sich entsprechend an. Irgendwann muss die Kompostierung solche und größere Auflösungen mit Langzeitstabilität berücksichtigen oder eine Kompromissmethode finden, die besser zu den Massen passt. Ich habe lieber stabile Neuzeichnungen an meinen Fenstern als Wackeln / Transparenz im Laufe der Zeit. Wenn ich wüsste, was mein System destabilisiert, würde ich es gerne deaktivieren.

Was ist die Version Ihres Nvidia-Treibers? Wenn Sie 390 oder 396 verwenden, verwenden Sie 415,25 auf dem Ubuntu PPA .

Die kombinierte Auflösung meiner Monitore beträgt 8560 x 1440, und ich sehe derzeit keine Verlangsamung mit Cinnamon in meinen PR-Filialen. In den wenigen Zeiträumen starte ich Cinnamon nicht für die Entwicklung neu.

Die Force Composition-Pipeline erhöht die Latenz. Ich empfehle die Verwendung im Allgemeinen nicht. Wenn bei Cinnamons vsync Probleme auftreten, stellen Sie sicher, dass in den nvidia-Einstellungen "Spiegeln zulassen" aktiviert und "Mit vblank synchronisieren" deaktiviert ist. Verwenden Sie keine Treiberumgehungen für Version 3.8 und älter.

Mir ist nicht klar, was Sie als Verzögerung betrachten. Ist der Cursor beim Ziehen nicht mit dem Fenster synchron? Oder allgemeine Eingabelatenz von Fenstern? Diese Dinge werden von verschiedenen Teilen des Compositor-Codes beeinflusst. https://github.com/linuxmint/muffin/pull/397 verbessert beides, und https://github.com/linuxmint/muffin/pull/392 verbessert letzteres - was ich gerne in 4.0 bekommen hätte, aber es braucht mehr Tests.

eine weitere Regression mit dem Flackern und der extremen Verzögerung

Lassen Sie uns diese Probleme getrennt halten, es gibt bereits einige Probleme mit dem Flackern, und ich habe nicht beobachtet, dass es unter 4.0 noch schlimmer ist. Natürlich muss es repariert werden, aber es ist schwierig, etwas zu reparieren, das nicht zuverlässig reproduziert werden kann.

Seit meinem letzten Upgrade bin ich auf nvidia 415.25-4, also innerhalb Ihrer Erwartungen.

Ich habe "Zulassen" (nicht zuvor ausgeführt), "Synchronisierung mit deaktiviertem vblank" (normalerweise ausgeführt) und die Force Full Compositing-Pipeline auf jeder Anzeige festgelegt (diesmal zurücksetzen).

Lag ist wie alles, was ich tue. Wenn ich zwischen den Fenstern klicke, führt das Neuzeichnen zu einer gewissen Verzögerung. Der Bildschirm wird für einige Sekunden angehalten, da er eingefroren ist. Ich habe kürzlich Overlord auf Steam gespielt, wo es dies tut, ziemlich ärgerlich während des Kampfes. Ich habe gelernt zu bemerken und zu verhindern, wenn es auftritt. Die Verwendung des Desktops führt auch zu diesem Stillstand. Wenn Sie dies eingeben, kommt es zu verschiedenen Verzögerungen / Ruckeln beim Klicken zwischen Fenstern und beim Tippen. Während des Tippens oder einer zufälligen Maus- oder Tastaturaktivität stoppt alles für ein oder zwei Sekunden.

Das Ziehen von Dingen verschlimmert das Problem, die meisten Dinge auf der Benutzeroberfläche neigen dazu, den Desktop zu verärgern und zu verzögern und die Dinge für ein oder zwei Sekunden visuell anzuhalten. 90 Tage schneller Vorlauf, dies führt zu einem 5-Sekunden-Stillstand bei allem, was Sie tun, wenn Sie sich für einen Treffer entscheiden, was alle paar Minuten und manchmal auch weniger ist.

In Bezug auf das Flackern habe ich festgestellt, dass dies auf allen Displays geschieht, zufällig in bestimmten Bereichen, nicht immer gleich, aber wie in einer Art Geisterbereich der Vergangenheit, der jeweils für Sekunden zu flackern beginnt und verschwindet. Dies gilt für alle 3 Anzeigen in 4k, eine kleine Teilmenge von jeweils einer.

Dies ist ein weiteres Artefakt beim Rendern in Software, aber seltsam, wenn es dies tut. Ich habe dies unter Hardware-Rendering nicht gesehen, aber in den letzten 90 Tagen viel mit Software getan. Schlimm genug unter Hardware ohne seltsamere Dinge in der Software.

Ich habe "Zulassen" (nicht zuvor ausgeführt), "Synchronisierung mit deaktiviertem vblank" (normalerweise ausgeführt) und die Force Full Compositing-Pipeline auf jeder Anzeige festgelegt (diesmal zurücksetzen).

Grundsätzlich schlug ich vor, Muffins vsync in Einstellungen -> Allgemein wieder zu aktivieren und die Force-Pipeline für die vollständige Komposition zu deaktivieren. Sie werden die größte Verzögerung feststellen, wenn beide aktiviert sind.

Das Flackern ist beim Rendern von Software und bei Verwendung bestimmter Clutter-Env-Variablen, die verwendet werden, wenn es aktiviert ist, definitiv schlimmer. Ich habe dies beim Booten mit dem Parameter nomodeset nicht gesehen, aber ein Flackern tritt auf, wenn der Nvidia-Treiber geladen wird, während Cinnamon Software-Rendering verwendet. Siehe # 7985.

Das "Abwürgen" -Verhalten klingt so, als würde der Thread zeitweise blockiert. Verwenden Sie Applets / Desklets / Erweiterungen von Drittanbietern? Überprüfen Sie mit gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions .

Ich bin mir nicht sicher, wie schmerzhaft es ist, ehrlich zu sein, oder normalerweise bin ich niedergeschlagen. Ich neige dazu, mit ihren Veröffentlichungen zu rennen, zu aktualisieren und ein wenig zu beten, dass das Problem einfach verschwindet. Allerdings nicht über größere Revisionen hinweg, jetzt 3.x bis 4.0. Ich versuche nicht viel abzuweichen, ich lebe von diesem System, einschließlich verschiedener VPNs, virtueller Maschinen und verschiedener anderer Integrationspunkte, die ich damit mache.

Ich bekomme kein Flackern unter der Hardware, obwohl es die zufällige Verzögerung gibt, die fast sofort dazu führt. Es wird schon schlimmer, kann ich sagen.

Ja, ich musste wieder aufhören, Zimt zu verwenden. Die Verzögerungen beim Neuzeichnen des Fensters haben mich erst nach ein paar Tagen umgebracht und bis zu 5 Sekunden Verzögerung bei jeder Fensteraktualisierung, die ich aktiv verwendet habe. Der Versuch, damit zu spielen, ist unmöglich. Normalerweise würde ich zum Software-Rendering zurückkehren, wo es normalerweise Monate dauert, bis die gleichen langen Verzögerungen bei Updates erreicht sind, aber das Software-Rendering in Version 4.0 ist völlig unbrauchbar.

KDE / Kwin ist immer noch ein Korb, fast das gleiche Problem, aber ich werde das Fenster einfach nie aktualisieren, da ich das Fenster minimieren und neu auswählen muss, um mit Änderungen neu zeichnen zu können.

Warum ist das für Compositors in verschiedenen DEs wirklich so schwer zu bekommen?

Ich habe die Erweiterungen von Drittanbietern überprüft, und nein, alles, was ich hatte, waren Zimterweiterungen und meistens Standarderweiterungen. Normalerweise habe ich das Kairo-Dock überlagert und es für benutzerdefinierte Dinge verwendet.

Ich habe viel Zeit damit verbracht, htop, iotop, nvtop und powertop und andere zu beobachten, um herauszufinden, warum dies geschieht, aber ich sehe nie, dass etwas Besonderes außerhalb von Cinnamon-Desktop als Ressourcenschwein auftaucht selbst und xorg im Laufe der Zeit.

Hier wird es natürlich immer unscharf, wie viel verhalten sich xorg, nvidia-Treiber oder Zimt schlecht? Ich kenne keine guten Möglichkeiten, diese intern zu debuggen. Ich bin offen für Ohren, wenn Sie eine gute Möglichkeit kennen, die Interna dieser Probleme zu beobachten, insbesondere Zimt selbst, da er mit der Zeit definitiv zu einem Ressourcenfresser wird.

Die Anwendungen machen ihr Ding, nur das Fenster wird in diesen "Verzögerungs" -Momenten nicht neu gezeichnet, also stimme ich zu, dass etwas blockiert wird, aber ich kann nicht herausfinden, was es ist.

Ich musste auf kde umsteigen, da die Verzögerung hier viel Kummer verursachte, aber kde sieht aus wie kein Champion und ist bereit, es noch einmal mit Zimt zu versuchen. Minze ist fast zu einfach, ich kann gnome3 nicht besonders leiden, insbesondere Ubuntus dysfunktionale Version davon, also komme ich trotz der Probleme immer wieder auf Zimt zurück. Ich würde wirklich gerne helfen, sie zu reparieren, wenn möglich, da ich offensichtlich nicht der einzige in diesem Thread bin.

Ich bin ein bisschen neugierig, was mit den anderen Leuten passiert ist, die das gesehen haben ...

Warum ist das für Compositors in verschiedenen DEs wirklich so schwer zu bekommen?

Das Optimieren von Compositing ist schwierig und erfordert viel Versuch und Irrtum. Es ist einfach nicht einfach, daran zu arbeiten.

Alles, was ich hatte, waren Zimterweiterungen und meistens Standard-Erweiterungen. Normalerweise habe ich das Kairo-Dock überlagert und es für benutzerdefinierte Dinge verwendet.

Meistens? Welche Erweiterungen werden verwendet? Das ist ein wichtiges Detail. Wir brauchen Informationen, die helfen können, das Problem zu reproduzieren, und keine Textmauern über Compositing. Vielen Dank!

Es gab ein Desklet, das aktiviert zu sein schien, bbcwx, ein Wetter-Applet, aber ich sah keine Anzeichen dafür, dass es vorhanden war oder vorher lief.

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

Mir ist klar, dass der Umgang mit dem Compositing eine komplexe Arbeit ist, daher möchte ich den Aufwand nicht herunterspielen, und ich schätze sie auf jeden Fall sehr, aber Compositing ist in jedem DE das schwächste Glied in allem unter Linux. Sogar in Windoze kann Aero ein Korb für Compositing sein, den ich bei meiner eingeschränkten Verwendung auf einem Dell-Laptop gefunden habe. Erstaunlich, wie viele einzigartige Bemühungen dies falsch zu machen scheinen, und ich frage mich nur, warum dies so notwendig ist, wenn es scheinbar unmöglich ist, es gut genug zu erreichen. Es scheint, dass es einen besseren Weg geben sollte.

Ah ok, wenn bbcwx aktiviert ist, aber nicht rendert, kann es sein, dass es sich schlecht verhält. Es gibt auch einige PRs, die ich für 4.0.x geöffnet habe und die die Leistung beeinträchtigen könnten, wie z. B. # 8180. Ich bin nicht sicher, wann dieser zusammengeführt wird, aber jeder sollte ihn verwenden oder zu GWL wechseln.

Ich verstehe die Frustration - deshalb habe ich angefangen, C zu lernen, um Muffins zu verbessern, aber ich kann nur offene PRs (die ich gemacht habe) tun. Grafiken unter Linux sind im Allgemeinen schon lange im Rückstand und haben erst vor kurzem nach einigen großen Änderungen (z. B. Protonen) aufgeholt. Es gibt viel zu tun, und mein Ziel ist es, Muffins so reaktionsschnell wie DWM in Windows 10 zu machen.

Ich erinnere mich nicht einmal ganz daran, es aktiviert zu haben, also muss es etwas Zufälliges und Vergessenes gewesen sein. Ich werde es entfernen, wenn ich herausfinden kann, wie.

Ich benutze Linux seit 2006 ganztägig und erinnere mich, dass ich vor / nach dem Compositing viel einfacher war. Ich habe mich jahrelang mit Ubuntu- und Compiz-Problemen befasst, als das begann. Es hat mich zu KDE, später zu Mate / Cinnamon und jetzt in letzter Zeit hin und her gebracht, was immer weniger nervt.

Bisher war es bei Cinnamon am schlimmsten, von 3.x auf 4.0 zu wechseln, aber kwin, compiz, mutter, alle scheinen unter einem inhärenten Ressourcenverlust zu leiden, der sich mit der Zeit nur noch verschlimmert. Da sie es alle tun, vermute ich oft, dass es sich um eine untergeordnete Komponente wie xorg oder nvidia handelt, die die Destabilisierung unter allen DEs verursacht, aber wirklich keine Möglichkeit, dies zu erkennen. Daher beginne ich mit der DE, schaue mir aber auch verschiedene * Tops an, um herauszufinden, was diese Grafikverzögerungen verursacht, bisher ohne Erfolg.

Ich neige dazu, den normalen Pacman-Upgrades von Arch zu folgen, um zu versuchen, Updates außerhalb davon sauber abzurufen. Ich bin mir nicht sicher, wie ich die nächsten Muffin-Releases in Arch ausprobieren soll, oder ich würde es tun.

Ich habe auch dieses Problem. Siehe Screenshot für meine Spezifikationen. Ich habe sogar 128 GB RAM: https://gyazo.com/1f0443df15097949a2314bebba6d12db

Ich habe meinen Wechsel zu XFCE> <gelöst (also nicht in Cinnamon gelöst).

@zenfulcoder Wo für das h * K verwenden Sie 128 GB RAM? Vielleicht ist es an der Zeit, dass Sie in Ihrem Fall sicher zu XFCE wechseln. Haha

@ gefährliche89 yah Ich liebe XFCE, ich bin gerade nach Jahren von XFCE zu Cinnamon gewechselt. Ich mochte Cinnamon für den modernen Desktop und deren Integration. Es ist schade, dass OpenGL zum Ausführen erforderlich ist.

Nun, mein Board hat es unterstützt, also habe ich es in XD eingefügt. Aber auf diese Weise laufe ich für die Arbeit nie aus. Grundsätzlich unbegrenzt. Aber in Cinnamon läuft es immer noch langsam !!

@zenfulcoder Willkommen dort, wo der Engpass ist. Es ist eigentlich nicht auf Ihre Speichergröße zurückzuführen, dennoch könnte es die Speichergeschwindigkeit / Latenz sein und was auch immer nicht. Und der Rest des PCs (Festplatten / Motherboard / hm .. etc.).

Trotzdem hängt es wahrscheinlich überhaupt nicht mit Ihren Spezifikationen zusammen, wie Sie im obigen Abschnitt sehen können. Es gibt einen Fehler in den Videotreibern, Xorg oder etwas in diesem Bereich.

@ Hazard89 Es ist definitiv ein Problem mit Cinnamon. Ich habe gelesen, dass die Version 4 vielleicht besser ist, aber für Debian noch nicht stabil genug.