Cinnamon: Retard de rafraîchissement de la fenêtre lors du déplacement de fenêtres

Créé le 14 oct. 2013  ·  73Commentaires  ·  Source: linuxmint/cinnamon

Cinnamon 2.0.2 et toutes les versions antérieures que j'ai utilisées semblent effectuer une quantité excessive de traitement lors du clic-glissement des fenêtres.

Cela se manifeste par un léger, mais perceptible bégaiement lorsque vous faites glisser la fenêtre, ce qui rend l'expérience de bureau semble lente - c'est extrêmement visible lorsque je démarre de Cinnamon vers Windows 7, où les fenêtres glissent en douceur.

Si je surveille le processus de cannelle avec top, je peux voir l'utilisation du processeur sans faire glisser, mais faire quelque chose comme lire une vidéo YouTube se situe à environ 5-10%. Au moment où je commence à faire glisser une fenêtre (une fenêtre Chrome pleine de texte) - l'utilisation du processeur passe à environ 30%.

BUG

Commentaire le plus utile

Eh bien, c'est intéressant, j'ai remarqué que le bégaiement que je voyais semblait se produire à la même fréquence que la mise à jour de l'applet System Monitor, alors je l'ai retiré du panneau et redémarré, et maintenant le bégaiement a disparu pour moi. Cela semble soutenir davantage la suggestion de

Tous les 73 commentaires

Je déteste dire "moi aussi", mais ... "moi aussi!" Je fonctionne sur une boîte un peu plus ancienne, avec Cinnamon fonctionnant sur Ubuntu 13.04. Tout le reste semble correct, c'est juste le glissement de fenêtre qui pose problème. Et le "bégaiement" est perceptible, après quoi la fenêtre saute juste au point suivant. Cela semble se produire lorsque vous faites glisser une fenêtre (chrome, uxterm). Faites-moi savoir quelles autres informations complémentaires je peux fournir. Je ne trouve rien d'intéressant dans mes journaux système.

Je peux le confirmer, mais j'ai une carte graphique très médiocre ...

Je rencontre aussi ces mêmes problèmes. J'utilise le dernier Cinnamon du ppa nocturne sur Ubuntu 13.10.

Je lance un système multi-têtes sur arch linux avec cannelle 2.0.2 actuellement (3x 1920x1080) J'ai essayé à la fois un 660 et mon 7870. Ils présentent tous les deux le même comportement, des fenêtres extrêmement lentes lors du déplacement ou du dimensionnement. Im utilisant le atm de pilotes opensource. (Essayera le catalyseur une fois qu'ils seront mis à jour pour fonctionner)

Sur mon système, c'est presque insupportable.

--- Mettre à jour --- si je désactive dans le panneau Paramètres Cinnamon -> Fenêtre Mosaïque et Edge Flip -> Fenêtre Mosaïque et accrochage - les fenêtres se déplacent à nouveau rapidement sur l'écran; J'ai eu cet indice en me déplaçant autour d'une fenêtre et j'ai eu le nouveau truc HUD qui me montrait la position que je pouvais mettre cette fenêtre; chaque fois que HUD apparaît, le lagg démarre.

Je peux confirmer le même comportement sur mon ordinateur portable; en utilisant Manjaro Linux et Cinnamon 2.0.6
J'ai un processeur dual-core P6100 et une carte graphique Intel HD 3000.
Je n'ai pas eu ce problème avant avec 1.6 ou 1.8.
Je cherchais une option avec Muffin pour désactiver le "contenu de la fenêtre" pendant le déplacement mais pas de chance pour l'instant, en utilisant l'éditeur Dconf.
Ce serait formidable si quelqu'un pouvait expliquer pourquoi cela se produit.
Continuez votre bon travail;)!

Le délai de glissement des fenêtres n'est rien comparé au redimensionnement des fenêtres (par exemple: gnome-terminal), cela peut prendre plusieurs secondes :-(

Je confirme ce bug avec Intel core I5 ​​et contrôleur graphique Intel (2ème génération).

Vous pouvez définir le seuil du HUD de tuile sur 1 et cela désactivera essentiellement l'affichage du HUD tout en gardant la tuile activée. Peut-être que dans la prochaine version, un moyen plus direct de le désactiver pourra être ajouté, ainsi qu'un ensemble de graphiques plus robustes pour animer le HUD.

Je peux confirmer ce bogue sur le processeur i7-2600K et le GPU AMD R9 290 (derniers pilotes bêta). Surtout sur mon écran 120hz. La désactivation de la mosaïque et de l'accrochage n'a pas aidé.

Quelle version de Cinnamon utilisez-vous? Une des causes de ce problème a été corrigée relativement récemment.

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

J'utilise Cinnamon 2.0.14. Essaiera d'installer le dernier.

Avoir le dernier muffin est probablement plus important. Si vous êtes sur muffin 2.0.4, vous n'avez pas encore la solution. Si vous exécutez 2.0.5, il l'aura.

(Je ne garantis pas que votre problème particulier est résolu, cela pourrait être une autre cause, mais cela vaut la peine de vérifier)

Je rencontre quelque chose de similaire avec Cinnamon 2.0.14 et Muffin 2.0.5 sur Mint 16 avec un i5-4440s avec des graphiques Intel HD 4600. Lorsque je fais glisser Windows, ils ne peuvent pas suivre le curseur de la souris. C'est comme si les fenêtres étaient attachées à mon curseur avec un petit élastique.

Voici une vidéo de ce que je vis. Est-ce un comportement normal? http://youtu.be/KylzMTZpD7w

Je peux confirmer que ce cas est toujours valable pour Cinnamon 2.2.14 et aussi Gnome Shell 3.12.2 sur Debian Jessie.

Je comprends aussi cela et c'est vraiment distrayant pour être honnête. Nettement moins fluide que Unity etc, et en effet Windows ...

Vivre la même chose dont je me suis plaint précédemment, mais aussi avec une NVidia GTX 760. Le problème est certainement pire avec plusieurs moniteurs.

Je reçois aussi cela sur Cinnamon 2.2.14, avec une NVidia GT 630 avec la version de pilote propriétaire 340.24 (et deux moniteurs). Lors de la rétrogradation à la version 304 du pilote, les fenêtres bougent à nouveau rapidement, mais je ressens alors des déchirures.

Le dimanche 10 août 2014 à 04:04:47 EEST, Andres Manz a écrit:

Je reçois aussi cela sur Cinnamon 2.2.14, avec une NVidia GT 630 avec le
pilote propriétaire version 340.24 (et deux moniteurs). Lors de la rétrogradation
à la version du pilote 304, les fenêtres bougent à nouveau rapidement, mais ensuite je
l'expérience de la déchirure.

Le décalage de la fenêtre disparaît lorsque le vsync est désactivé via le
Variables d'environnement. Le pilote AFAIK Nvidia 304 n'active pas vsync par
par défaut (contrairement aux plus récents), cela peut donc expliquer pourquoi vous avez
faire glisser et déchirer lorsque vous revenez à celui-ci.

Cependant, une utilisation élevée du processeur est répandue indépendamment de vsync.

Peut confirmer que les fenêtres sont beaucoup moins lentes si je ne fais aucune tentative pour activer vsync (pilotes Intel), mais alors les vidéos sont inaccessibles.

C'est aussi étrange que linux mint n'ait pas ce bogue, et arch linux a.

@startas Non, je l'obtiens sur Mint 17.

Encore plus étrange depuis que j'ai publié dans ce numéro, je n'ai plus eu le problème. Depuis, j'ai installé cinnamon sur plusieurs configurations de périphériques, matériels et logiciels (distributions).

C'est bizarre - j'ai "résolu" ce problème (je n'ai que des graphiques Intel HD, donc cela pourrait ne fonctionner que pour les graphiques Intel) en recompilant xf86-video-intel avec le drapeau "--disable-dri3", et en recompilant lib32-mesa avec le même flag "--disable-dri3", bien sûr, vous devez également supprimer le drapeau "--enable-dri3".
Alors que j'utilise Linux 64 bits, compiler le paquet mesa 64 bits sans dri3 et l'installer plante le bureau cinnamon, mais recompiler uniquement xf86-video-intel et la version 32 bits de mesa pour les systèmes 64 bits "a corrigé ce problème", il a également correction d'énormes retards dans le chrome.
Seule la désactivation de dri3 dans les pilotes 2D ne fonctionne pas, mais la désactivation de dri3 dans la version 32 bits de mesa et son installation a fonctionné, je me demande pourquoi - ce package n'est même pas installé par défaut, car Linux 64 bits utilise la cannelle 64 bits, il utilise donc 64 bits mesa, et je n'ai aucune idée de comment cela a fonctionné: D

sauf qu'il y a un problème avec cela, DRI3 n'existait pas lorsque ce problème a été créé pour la première fois.

Actuellement, Arch Linux diables DRI3 par défaut je pense?

Ce problème semble être lié à quelque chose que je vois dans Kerbal Space Program sur Linux (avec Cinnamon): des cadres parfaits, sauf lorsque je clique et maintiens la souris pour faire un panoramique autour d'une fusée - puis il bégaye et saute mal. Cinnamon fait peut-être une sorte de blocage dans la boucle de rafraîchissement des événements de souris?

Dans arch Linux, xf86-video-intel est compilé sans dri3, mais mesa est compilé avec dri3.

sur mon PC assez rapide, le redimensionnement des fenêtres avec de la cannelle est une douleur et j'aimerais une option pour désactiver la visualisation en temps réel du contenu de la fenêtre. xfce fait cela d'une très bonne manière.

Cela se produit mais uniquement sur mon moniteur externe, sur un Macbook ("fin 2014") avec des graphiques Intel. La fenêtre affichera également les artefacts de déchirement, encore une fois uniquement sur l'écran externe. Le décalage ne change pas sensiblement si j'active "TearFree" mais il corrige le déchirement. Je redimensionne l'affichage externe 2x2 avec xrandr.

edit: Je dois noter que quelque chose comme glxgears ne souffre pas de réduction du framerate si je le traîne sur cet écran, en fait il rapportait ~ 71 fps sur un moniteur 60Hz, malgré le mouvement qui le faisait paraître <10 images par seconde. En le laissant seul, il fonctionne normalement.

edit2: il semble que la mise à l'échelle ne change pas non plus le décalage.

@wrouesnel et autres ...

Le problème KSP est probablement dû au fait que le taux d'interrogation de votre souris est trop élevé, en particulier si vous avez une souris de jeu, telle qu'une Razer DeathAdder ou similaire (que j'utilise). Le tutoriel suivant devrait vous aider:

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

J'ai enregistré une vidéo montrant le problème que j'ai (problème de glissement du navigateur Chromium, tandis que Nemo et Firefox sont exécutés à des fins de comparaison uniquement): https://youtu.be/Ec99EYjwiqY
J'ai le même problème avec IntellJ et parfois avec Pidgin ou moins avec Nemo. J'utilise Mint 17.3 et Cinnamon 2.8.6 avec des pilotes propriétaires amd. Choses à noter:

-Menthe 17.3 avec cannelle 2.8.6
-ne pouvait pas charger les pilotes gpu open source pour les tester, cela m'a gardé en mode de rendu logiciel maintenant (je me souviens que l'open source xorg fonctionnait bien lorsque j'ai installé 17.0 Mint il y a quelques mois)
-Forcer la désactivation de vsync dans amd propriétaire CCC aide un peu moins de fenêtres retardées, mais cela rend l'écran particulièrement déchiré lors du défilement des sites Web
-Lorsque Cinnamon vient de démarrer, tout fonctionne correctement, pas de fenêtres traînantes latentes, pas de redimensionnement lent. Le problème est présent après un certain temps (par exemple 10 à 40 minutes après le démarrage de Chromium)
-Redémarrer Cinnamon (ctrl + alt + esc) aide temporaire (au-dessus du point)
- (modifier): cela ne s'est pas produit avant sur 17.2 et Cinnamon 2.6 si je me souviens bien, mais j'avais un plus gros problème de déchirement à l'époque.

Éditer:
Les mêmes choses se produisent en utilisant des pilotes open source, on a réussi à les réinstaller.

Exécution de Fresh Mint 17.3 Cinnamon à partir d'une clé USB, le même problème que celui expliqué ci-dessus.
Vérifié Ubuntu Gnome3 et Ubuntu Mate pour comparaison. En exécutant les deux depuis USB pendant assez longtemps, je n'ai remarqué aucun problème / ralentissement.

D'une manière ou d'une autre, il semble que cela soit lié au GPU, cela arrive en particulier aux logiciels prenant en charge le GPU, comme Chromium.
La deuxième chose à noter est que cela semble se produire plus rapidement tout en ayant intelihide pour la barre de menus et en continuant à poinçonner la barre de menus avec la fenêtre Chromium. J'entends les fans sur un ordinateur portable commencer à travailler plus fort. Il est préférable de faire glisser la fenêtre Chromium en la faisant circuler sur le bureau.

"Désactiver la composition pour les fenêtres plein écran" activé / désactivé - aucun changement

Il est lent à réapprendre même avec la barre de menus poinçonnage, le moyen le plus simple est de simplement naviguer sur Internet pendant un certain temps, mais je comprends que cela pourrait être un enfer pour le débogage.

J'ai aussi ce problème - mais ce que j'ai remarqué, c'est que les fenêtres prennent du retard après un certain temps - mais si j'en ouvre de nouvelles, elles ne le font pas.

Par exemple, si je laisse un terminal assis là pendant une heure, il bégayera tout en traînant un peu, mais un terminal nouvellement ouvert se comportera très bien.

Et oui, c'est à ce moment que Chrome est ouvert (qui est fondamentalement ouvert tout le temps).

Ce n'est pas grave car tous les autres aspects semblent fonctionner correctement (par exemple, vous ne remarquez pas plus de décalage dans les jeux ou quelque chose du genre) - la seule autre chose étrange que j'ai remarquée est que l' écran de verrouillage prend environ 10 secondes. à charger (je n'avais jamais remarqué cela avant de passer à Mint 17.3)


PS: J'ai remarqué que le processus cinnamon --replace montrera une utilisation assez élevée du processeur (environ 16% sur mon système) quelque temps après avoir déplacé une fenêtre _laggy_.

Intellihide désactivé, régler le panneau pour qu'il s'affiche toujours. Fonctionnant actuellement OS pendant quelques heures et surprise! pas de décalage! Je me sens juste comme au paradis.

Je peux confirmer le décalage de la fenêtre derrière le curseur, sous Linux Mint 17.3, Cinnamon 2.8.6, avec le pilote propriétaire nvidia 352.63. Très ennuyant! Le problème est indépendant de la composition activée ou non!

Je peux également confirmer le décalage avec Mint 17.3, Cinnamon 2.8.6 et les graphiques intégrés du i5-4210U ou d'un nVidea GeForce 820M.
J'ai joué un peu avec les paramètres d'affichage / masquage du panneau et il semble que le décalage n'est là que lorsque le panneau est affiché. Lorsque je le configure pour masquer automatiquement, tous les glissements de fenêtre sont lisses.
(Ouais je sais que c'est tout le contraire du commentaire de DarekDeo).

Peut-être pas tout à fait le contraire, d'après nos deux commentaires, il semble que quelque chose ne va pas avec le panneau. :)

edit: ou du moins lié à lui.

J'ai aussi ce problème. Quelqu'un a essayé un pilote graphique différent? J'ai eu ce problème sur Xubuntu 15.10 et une fois que j'ai changé de pilote, tout fonctionnait bien. Je n'arrive pas à trouver cette option ici? Je vais aux pilotes dans le panneau des paramètres et une liste vide apparaît.

Configuration: Fedora 23, Cinnamon, GDM, pilotes propriétaires Nvidia (également avec Nouveau)

Je rencontre également un bégaiement lorsque je fais glisser des fenêtres, ainsi que lorsque je tape ou que je fais défiler un fichier dans Vim. Par exemple, pendant que je tape, quelques lettres apparaissent avec la touche, puis le curseur se bloque pendant quelques millisecondes, puis les lettres que j'ai tapées pendant le blocage apparaissent toutes.

Le bégaiement semble se produire régulièrement. Si je devais deviner, je dirais environ toutes les 500 ms. Fait intéressant, si je déplace une fenêtre rapidement pendant un certain temps, le haut montre que Xorg prend parfois un pourcentage énorme du processeur (~ 53%) lors du déplacement de fenêtres ... cela ne semble pas correct. Des idées?

EDIT: J'ai démarré le CD Fedora 23 Cinnamon Spin Live et, fait intéressant, je n'ai rencontré aucun bégaiement. Mais, en utilisant le même environnement DM (Cinnamon, lightdm, pilotes nouveau) dans mon installation de disque dur le fait toujours. Je peux essayer d'installer le spin Cinnamon directement sur le Live CD sur une autre machine pour voir si le problème persiste; Je ferai rapport avec tous les résultats.

Wow, d'accord. Merci @DarekDeo, cela fonctionne beaucoup mieux lorsque le panneau intelligent est désactivé. Dommage que je ne puisse pas regarder de vidéos Youtube dans le grand lecteur lorsque mon navigateur est maintenant en plein écran, c'est pourquoi j'ai activé ce panneau en premier lieu, mais les fenêtres se détérioraient.

Je trouve étrange à quel point toutes les fenêtres sont encore lentes, elles ne sont pas insupportables, mais si je retourne à Windows, mon 144 Hz donne à tout un aspect et une sensation si fluides, en déplaçant les fenêtres et elles se sentent toutes si solides et stables, revenez Linux et mon 60 sont presque plus fluides que mes 144 et les fenêtres donnent l'impression qu'elles sont censées être en retard lorsque vous les faites glisser.

Je veux aussi juste ajouter que le panneau intelligent semble également affecter les fenêtres, mon navigateur avait beaucoup clignoté en blanc en raison de problèmes, en a essayé quelques-uns pour voir lequel ne l'avait plus expérimenté, j'ai pensé que quelque chose pourrait être cassé avec de la cannelle ou mon pilote graphique, il s'avère que le panneau était le problème @ _ @

Eh bien, c'est intéressant, j'ai remarqué que le bégaiement que je voyais semblait se produire à la même fréquence que la mise à jour de l'applet System Monitor, alors je l'ai retiré du panneau et redémarré, et maintenant le bégaiement a disparu pour moi. Cela semble soutenir davantage la suggestion de

J'ai le même problème en fait, la mise à jour vers une version plus récente de Cinnamon l'a rendu un peu meilleur, mais mon bureau Nvidia (i5-3570k, Nvidia 780ti) n'est toujours pas aussi fluide que mon ordinateur portable graphique Intel beaucoup moins puissant (i7-4500u, Intel graphiques 4400).

Les deux utilisent Mint 17.3, Cinnamon 3.04 (canal nocturne) et le noyau 4.4.0-22.

Les pilotes utilisés sont les 364 de Nvidia (364.19-0ubuntu0 ~ gpu14.04.3) du PPA des pilotes Nvidia et les pilotes Intel inclus dans le noyau.

@ davidva-cml merci, la suppression de l'applet Sytem Monitor a résolu le problème pour moi!

Désactivé la "synchronisation avec vblank" dans les paramètres de nvidia xserver et le redimensionnement d'applications telles que Telegram est désormais fluide

C'est toujours un problème pour moi.
J'utilise une nouvelle installation d'Ubuntu 16.04.1, en utilisant une Nvidia GTX 1070 avec la version de pilote 375, donc les performances ne devraient pas être un problème.

@JosephMcc , pouvons-nous marquer ce problème comme un bogue?

@ davidva-cml Avez-vous réussi à le faire réparer? Je vois aussi Xorg en plus de l'utilisation du processeur lors du glissement de fenêtres ... Peut-être que nous devrions le signaler comme un problème Xorg. Bien que cela puisse toujours être un problème de cannelle après tout. Le moyen le plus simple de reproduire est d'exécuter glxgears en arrière-plan tout en faisant glisser les fenêtres.

Cependant, certaines personnes dans ce problème pourraient souffrir d'un problème de retard totalement différent (qui pourrait être lié à la cannelle).

J'ai peur d'avoir le même problème. Mais j'ai un PC vraiment puissant (Core i7-5930K 3,5 GHz 6 cœurs + Nvidia TITAN X exécutant le dernier pilote nvidia + 32 Go de RAM et mon système d'exploitation installé sur un SSD). Les performances ne devraient donc pas être un problème. Mais quand même, chaque fois que j'essaye de faire glisser une fenêtre, j'ai de la lenteur comme tout le monde dans ce fil. Mais les applications les plus ouvertes que j'ai, plus c'est lent!
Lorsque je surveille (htop), je peux voir que le processus Xorg prend 90% ou plus de l'utilisation du processeur. Donc ça pourrait venir de Xorg, pas directement de cannelle.
Ce devrait être formidable d'avoir des commentaires pour comprendre ce qui se passe là-bas.
Merci.

Fonctionnement :
Noyau Linux 4.10.0-générique
FerenOS (qui utilise la dernière version de la distribution Linux Mint)
Courir la cannelle 3.4.6

Je suis curieux de savoir si d'autres ont trouvé des solutions pour cela ces derniers temps, car cela s'est calmé.

Pour moi, Cinnamon commence à se déstabiliser avec ce décalage croissant du redémarrage au fil du temps, jusqu'à ce que cela devienne presque trop ennuyeux pour en prendre plus, et généralement je trouve que je dois le redémarrer dur car l'écran ne se réveillera plus du sommeil. Comme le dernier article, c'est un ordinateur puissant (20 cœurs, 40 threads, double xeon, 128 Go de RAM, nvidia 1070, double nvme, 3x écrans 4k), donc les performances ne sont pas un problème, et je ne comprends pas cela avec d'autres ordinateurs de bureau environnements autres que kde (qui a ses propres problèmes de composition). J'ai désactivé vblank et la plupart des autres fonctionnalités de gl, et je déstabilise toujours, généralement en une semaine, mais jamais d'erreurs révélatrices de quelque chose.

J'utilise les pilotes Arch linux, Cinnamon 3.8.1-1, 4.16.13 et nvidia 396.24. Je continue à m'améliorer en espérant que cela disparaît, mais jamais.

Apparemment (comme c'est le cas avec la plupart des ordinateurs de bureau actuellement), la réponse est simplement d'utiliser le rendu logiciel du bureau. J'ai réussi à passer quelques semaines la dernière fois avant d'obtenir un délai d'affichage de 5 secondes environ toutes les minutes environ, ce qui devient plutôt exaspérant avec le temps.

Habituellement, je passe simplement à un autre bureau, KDE (en priant pour qu'ils le réparent aussi) ou Mate (marco a tendance à se comporter, mais le bureau manque par rapport aux autres) après un pacman -Syyu, mais cette fois, j'ai remarqué le rendu du logiciel cinnamon mode. Après une semaine d'utilisation normale avec le rendu logiciel, je commencerais normalement à obtenir le décalage après quelques jours, mais avec le mode logiciel, cela a été fluide et ne voit vraiment aucun inconvénient dans les performances de l'utilisation du bureau.

C'est dommage que ce bogue de compositeur semble persister, mais il est presque certainement lié à la vidéo / gl. Les compositeurs sont le fléau de tous les bureaux Linux que je trouve, je n'en ai pas encore trouvé un qui se comporte correctement, même windoze aero que j'ai trouvé en 4k est de la merde absolue livrée avec mon xps 9560.

Une bonne solution consiste à ajouter CLUTTER_VBLANK=none à / etc / environment et à activer le pipeline de composition de force sur tous les moniteurs dans nvidia-settings sous Configuration d'affichage -> Avancé. Cela déplace la gestion de vsync du compositeur vers le pilote, et aide également sur amdgpu avec TearFree activé dans la configuration xorg.

Merci pour cela, j'ai défini dans mon environnement / etc /, mais je n'ai pas trouvé le besoin d'essayer la version matérielle, car elle semble seulement inviter le drame et le chaos. Je suis assez satisfait de la version rendue par le logiciel jusqu'à présent, de certains retards de dessin dans cairo-dock et d'autres applications, mais pas vraiment comme la version matérielle qui fait caca sur elle-même.

Intéressant, même en mode logiciel maintenant, je développe le même retard, mais à un rythme beaucoup plus lent qu'avec un rendu gpu complet. Cela ressemble à une sorte de fuite de ressources, mais si ce n'est pas un rendu direct contre le GPU, je présumerai un bug dans la gestion des ressources sur le bureau.

Quels sont les commentaires, les journaux, les débogages, etc. utiles pour résoudre ce problème? Je ne vois rien d'anormal nulle part, à part le bureau qui panique à des intervalles aléatoires / communs.

Aussi pour clarifier, je pense que cela est en grande partie lié aux hautes résolutions auxquelles j'utilise cela. Mon bureau fonctionne à 11520x2160 (3x écrans 4k), ce qui taxe tout bureau que je trouve qui essaie même l'accélération GPU. Je ne pense pas que quiconque prend en compte ce genre de chose, mais avec 4k, 5k et maintenant 8k à venir, la lutte est réelle. C'est pourquoi le compositing semble casser sous n'importe quel bureau, y compris unity, kde, cannelle, ou même mate / marco avec un rendu direct contre gpu à cette échelle.

C'est quelque chose à noter pour les développeurs, l'échelle de résolution du rendu composite est correctement un problème depuis ~ 2010, lorsque j'exécutais des écrans 6x 1080p sous Linux avec l'avènement du compositing.

Je suis donc de retour pour vérifier cela, après avoir connu des retards de 5 secondes dans le rafraîchissement de la fenêtre sous le logiciel de composition le plus récemment après environ 80 jours de disponibilité, j'ai mis à niveau à nouveau pour voir ce qui était nouveau et, espérons-le, amélioré. En bref: pas tellement.

Maintenant à 4.0.7 paquets de base de cannelle, et le lancement avec le rendu logiciel comme précédemment était épouvantable avec d'horribles problèmes de scintillement et de rafraîchissement étranges autour de certaines parties des fenêtres (c'est-à-dire les boutons minimiser / quitter en particulier). Essayer le mode matériel, cela fonctionne sans cela, mais presque immédiatement, j'ai commencé à obtenir un décalage de rafraîchissement en quelques jours d'utilisation qui ne cesse de croître comme avant avec le mode matériel qui m'a poussé à utiliser un logiciel. Le logiciel semble être un panier dans la 4.0 jusqu'à présent, mais le rendu matériel a toujours ce problème depuis des années.

Que faudrait-il pour résoudre ce problème? Les résolutions ne deviennent pas plus petites dans les écrans, et ces compositeurs ne semblent toujours pas gérer quoi que ce soit au-delà des anciennes résolutions HD.

Le mode de rendu du logiciel @mikebutash n'a jamais été conçu pour être utilisé lorsque le pilote graphique est chargé. C'est pour le mode VGA.

Il existe un assortiment de PR ouverts pour 4.2. Si vous vous sentez à l'aise de les tester, vous pouvez consulter mes branches PR sur le repo Muffin. L'autre option serait de désactiver vsync dans Paramètres -> Général et d'activer le pipeline de composition de force dans nvidia-settings. Il n'y a rien d'autre à faire pour résoudre ce problème pour la série 4.0.x.

Edit: Voir également cette page wiki .

@jaszhix , a convenu que ce n'était pas

J'avais fait à la fois vsync et pipeline forcé par recommandation auparavant, mais j'avais remarqué la vérification en ce moment que le pipeline de composition complète de force était à nouveau désactivé dans nvidia-settings, donc réactiver et voir comment cela se passe. Je vois déjà encore un décalage occasionnel après l'avoir activé sur tous les écrans, mais il reste à voir comment s'il s'aggrave régulièrement à mesure que cela a tendance à le faire.

Si tous les DE sont tellement déterminés à composer, ce serait bien s'ils garantissaient la stabilité à grande échelle de la résolution, car ils souffrent tous les mêmes problèmes avec de grandes résolutions. Cinnamon on mine agit comme une fuite de mémoire, avant le redémarrage / mise à niveau après 90 jours environ, je verrais cinnamon-desktop utilisant couramment 80 à 90% d'un processeur en cours de traitement d'un top-talker dans htop (ne semblait pas fil bien au cœur car j'ai 39 autres threads qu'il pourrait utiliser), et utilisé beaucoup de mémoire, environ 20-30 Go (quelque chose à dire ayant 128 Go dans ce système). Il doit y avoir un moyen de tester cela à grande échelle, et une sorte de test de résistance de type valgrid semble-t-il. Après environ 90 jours d'utilisation ici, la cannelle est toujours prête à éclater, et c'est dans le rendu logiciel. Il mourra généralement dans une semaine dans le matériel. KDE souffre à peu près de la même manière.

La plupart des gens n'utilisent pas couramment une résolution de 11200x2160, mais il ne s'agit que d'écrans 3x 4k, qui deviennent de plus en plus courants et moins chers chaque jour, ou s'ajustent en conséquence. À un moment donné, le compostage doit prendre en compte des résolutions comme celle-ci, et plus, avec une stabilité à long terme, ou trouver une méthode de compromis qui conviendra mieux aux masses. Avoir plutôt des redessins stables sur mes fenêtres que des oscillations / transparence au fil du temps. Si je savais ce qui déstabilisait mon système, je le désactiverais volontiers.

Quelle est la version de votre pilote Nvidia? Si vous utilisez 390 ou 396, utilisez 415.25 sur le PPA Ubuntu .

La résolution combinée de mes moniteurs est de 8560x1440, et je ne vois aucun ralentissement avec Cinnamon au fil du temps sur mes branches PR actuellement, dans les quelques périodes où je ne redémarre pas Cinnamon pour le développement.

Le pipeline de composition de force ajoute une certaine latence. Je ne recommande généralement pas son utilisation, et si vous rencontrez des problèmes avec le vsync de Cinnamon, assurez-vous que "Autoriser le retournement" est activé dans nvidia-settings et que "Sync to vblank" est désactivé. N'utilisez pas de solutions de contournement de pilote destinées aux versions 3.8 et antérieures.

Je ne vois pas clairement ce que vous considérez comme un décalage - est-ce que le curseur n'est pas synchronisé avec la fenêtre lors du déplacement? Ou latence d'entrée générale des fenêtres? Ces choses sont affectées par différentes parties du code du compositeur. https://github.com/linuxmint/muffin/pull/397 améliore les deux, et https://github.com/linuxmint/muffin/pull/392 améliore ce dernier - que j'aurais aimé entrer dans 4.0, mais il a besoin de plus de tests.

une autre régression avec le scintillement et le décalage extrême

Gardons ces problèmes séparés, il y a déjà quelques problèmes concernant le scintillement, et je n'ai pas observé que c'était pire sur 4.0. Bien sûr, il doit être corrigé, mais il est difficile de réparer quelque chose qui ne peut pas être reproduit de manière fiable.

Donc, depuis ma dernière mise à jour, je suis sur nvidia 415.25-4, donc conforme à vos attentes.

J'ai défini autoriser le basculement (pas fait auparavant), la synchronisation avec vblank désactivée (généralement effectuée) et la force du pipeline de composition complet sur chaque écran (réinitialiser cette vérification de l'heure).

Lag, c'est comme tout ce que je fais. Si je clique entre les fenêtres, le rafraîchissement entraîne un certain décalage, l'écran s'arrêtant pendant quelques secondes à la fois comme figé. J'ai récemment joué à Overlord sur Steam là où il le fait, assez ennuyeux pendant la bataille. J'ai appris à remarquer et à anticiper quand cela se produit. L'utilisation du bureau entraîne également ce décrochage, ce qui entraîne divers retards / bégaiements de clic entre les fenêtres et pendant la saisie. Tout s'arrête pendant une seconde ou deux pendant la frappe ou toute activité de la souris ou du clavier au hasard.

Faire glisser les choses a tendance à exacerber le problème, la plupart des éléments de l'interface utilisateur ont tendance à mettre en colère et à retarder le bureau, bloquant les choses visuellement pendant une seconde ou deux. Avance rapide de 90 jours, cela se traduit par un décrochage de 5 secondes dans tout ce que vous faites quand il décide de frapper, ce qui est toutes les quelques minutes, et parfois moins.

En ce qui concerne le scintillement, j'ai remarqué que cela se produisait sur tous les écrans, certaines zones au hasard, pas toujours les mêmes, mais comme une sorte de zone fantôme du passé qui commencera à clignoter pendant quelques secondes à la fois et disparaîtra. C'est sur les 3 écrans en 4k, un petit sous-ensemble d'un à la fois.

C'est un autre artefact du rendu dans un logiciel semble-t-il, mais bizarre quand il le fait. Je n'ai pas vu cela sous le rendu matériel, mais en ai fait beaucoup avec le logiciel au cours des 90 derniers jours environ. Assez mauvais sous le matériel sans choses plus étranges dans le logiciel.

J'ai défini autoriser le basculement (pas fait auparavant), la synchronisation avec vblank désactivée (généralement effectuée) et la force du pipeline de composition complet sur chaque écran (réinitialiser cette vérification de l'heure).

Fondamentalement, ce que je suggérais était de réactiver le vsync de muffin dans Paramètres -> Général, et de désactiver le pipeline de composition complet de force. Vous rencontrerez le plus de décalage si les deux sont activés.

Le scintillement est certainement pire sur le rendu logiciel et lors de l'utilisation de certaines variables d'environnement Clutter qui sont utilisées lorsqu'il est activé. Je n'ai pas vu cela se produire lors du démarrage avec le paramètre nomodeset , mais un scintillement se produira si le pilote Nvidia est chargé alors que Cinnamon utilise le rendu logiciel. Voir # 7985.

Le comportement de "blocage" semble que le thread se bloque par intermittence, utilisez-vous des applets / desklets / extensions tiers? Vérifiez avec gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions .

Je me suis trompé, je ne sais pas à quel point il y a de la douleur sous la voûte plantaire pour essayer d'être honnête, ou normalement je suis déprimé. J'ai tendance à courir avec leurs versions, à mettre à jour et à prier un peu pour que le problème disparaisse. Pas à travers les révisions majeures maintenant cependant, 3.x à 4.0 maintenant. J'essaie de ne pas trop dévier, je gagne ma vie avec ce système, y compris divers VPN, machines virtuelles et divers autres points d'intégration que j'en fais.

Je n'obtiens pas le scintillement sous le matériel, même si le décalage aléatoire démarre presque immédiatement. Ça empire déjà, je peux le dire.

Ouais, j'ai dû arrêter à nouveau d'utiliser Cinnamon, les décalages de rafraîchissement de la fenêtre me tuaient après quelques jours seulement, obtenant jusqu'à 5 secondes de décalage dans n'importe quelle fenêtre rafraîchissante que j'utilisais activement. Essayer de jouer avec cela est impossible. Normalement, je reviendrais au rendu logiciel où il faut généralement des mois pour obtenir les mêmes longs délais de mise à jour, mais le rendu logiciel maintenant en 4.0 est entièrement inutilisable.

Sur un rythme accéléré, KDE / Kwin est toujours un panier, presque le même problème, mais je ne vais tout simplement jamais obtenir la fenêtre à actualiser du tout, ayant à minimiser et resélectionner la fenêtre pour pouvoir redessiner avec les modifications.

Pourquoi est-ce si difficile à obtenir pour les compositeurs de différents DE?

J'ai vérifié les extensions tierces, et non, je n'avais que des extensions cinnamon, et surtout des extensions par défaut. J'avais l'habitude de superposer cairo-dock et de l'utiliser pour des choses personnalisées.

J'ai passé beaucoup de temps à regarder htop, iotop, nvtop et powertop, et d'autres à essayer de trouver pourquoi cela se produit, mais je ne vois jamais rien de particulier apparaître comme un cochon de ressources de quelque manière que ce soit, en dehors de cinnamon-desktop lui-même et xorg au fil du temps.

C'est bien sûr là que ça devient toujours flou, à quel point xorg, les pilotes nvidia ou la cannelle se comportent-ils mal? Je ne connais aucun bon moyen de les déboguer en interne. Je suis ouvert aux oreilles si vous connaissez un bon moyen de surveiller les éléments internes de ceux-ci pour des problèmes, en particulier la cannelle elle-même, car elle devient définitivement une source de ressources avec le temps.

Les applications font leur travail, seule la fenêtre n'est pas redessinée pendant ces moments de «décalage», donc je suis d'accord que quelque chose se bloque, mais je ne peux pas comprendre ce que c'est.

J'ai dû passer à kde car le décalage causait beaucoup de chagrin ici à utiliser enfin, mais kde ne ressemble à aucun champion, donc prêt à essayer à nouveau la cannelle. La menthe est presque trop simple, je ne supporte pas beaucoup gnome3, en particulier la version dysfonctionnelle d'ubuntu, alors je reviens toujours à la cannelle malgré les problèmes. J'adorerais vraiment aider à les corriger si possible car évidemment je ne suis pas le seul à ce fil.

Je suis un peu curieux de savoir ce qui est arrivé aux autres personnes voyant cela ...

Pourquoi est-ce si difficile à obtenir pour les compositeurs de différents DE?

L'optimisation de la composition est difficile à faire et nécessite de nombreux essais et erreurs. Ce n'est tout simplement pas une chose facile à travailler.

tout ce que j'avais, c'était des extensions cannelle, et surtout des extensions par défaut. J'avais l'habitude de superposer cairo-dock et de l'utiliser pour des choses personnalisées.

La plupart? Quelles extensions sont utilisées? C'est un détail important. Nous avons besoin d'informations qui peuvent aider à reproduire le problème, et non d'un mur de textes à propos de la composition. Merci!

Il y avait un desklet qui semblait activé, bbcwx, une applet météo, mais je n'en ai vu aucun signe présent ou en cours d'exécution auparavant.

[ user @ host ~] $ gsettings obtient des applets activées 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 obtient des desklets activés org.cinnamon
[' [email protected] : 1: 50: 50']
[ user @ host ~] $ gsettings obtient org.cinnamon enabled-extensions @ comme []

Je me rends compte que gérer la composition est un travail complexe, donc je ne veux pas minimiser l'effort, et je les apprécie certainement au fond, mais la composition est dans chaque DE J'utilise le maillon le plus faible de tout sous Linux. Même dans Windoze, Aero peut être un panier pour la composition que j'ai trouvé dans mon utilisation limitée de celui-ci sur un ordinateur portable Dell. Incroyable combien d'efforts uniques semblent se tromper, alors je me demande simplement pourquoi cela est si nécessaire alors qu'il semble impossible d'accomplir suffisamment bien. Il semble qu'il devrait y avoir un meilleur moyen.

Ah ok, donc si bbcwx est activé mais pas de rendu, il se peut qu'il se comporte mal. Il y a aussi quelques PR que j'ai ouverts destinés à la version 4.0.x qui pourraient affecter les performances, comme # 8180. Je ne sais pas quand celui-ci sera fusionné, mais tout le monde devrait l'utiliser ou passer à GWL.

Je comprends la frustration - c'est pourquoi j'ai commencé à apprendre le C pour pouvoir améliorer les muffins, mais je ne peux pas faire grand chose à part les PR ouverts (ce que j'ai fait). Les graphismes sous Linux en général sont en retard depuis longtemps et ont récemment commencé à rattraper leur retard après de gros changements (par exemple, proton). Il y a beaucoup de travail à faire et mon objectif est de rendre le muffin aussi réactif que DWM dans Windows 10.

Je ne me souviens même pas très bien de l'avoir activé, donc ça devait être quelque chose d'aléatoire et oublié. Je vais le supprimer, si je peux comprendre comment.

J'utilise Linux depuis 2006 à plein temps, et je me souviens avant / après la composition, et la vie était bien plus simple avant. J'ai traité des problèmes d'Ubuntu et de Compiz pendant des années quand cela a commencé, cela m'a conduit à KDE, plus tard à Mate / Cinnamon, et maintenant dans les deux sens ces derniers temps, ce qui est le moins nul.

Jusqu'à présent, passer de 3.x à 4.0 était le pire avec Cinnamon, mais kwin, compiz, marmonner, ils semblent tous souffrir d'une fuite de ressources inhérente qui s'aggrave avec le temps. Comme ils le font tous, je soupçonne souvent que c'est un composant de niveau inférieur, comme le pilote xorg ou nvidia, qui provoque la déstabilisation de tous les DE, mais vraiment aucun moyen de le dire. Ainsi je commence par le DE, mais je regarde aussi divers * top's pour essayer de comprendre ce qui cause ces retards graphiques, jusqu'ici en vain.

J'ai tendance à suivre les mises à niveau normales de pacman pour essayer de tirer des mises à jour en dehors de cela proprement, je ne sais pas comment essayer les prochaines versions de muffin dans Arch ou je le ferais.

J'ai aussi ce problème. Voir la capture d'écran pour mes spécifications. J'ai même 128 Go de RAM: https://gyazo.com/1f0443df15097949a2314bebba6d12db

Résolu mon passage à XFCE> <(donc ce n'est pas résolu dans Cinnamon)

@zenfulcoder Où le h * K pour

@ danger89 yah j'adore XFCE, je viens de passer à Cinnamon après des années de XFCE. J'ai aimé Cinnamon pour le bureau moderne et leurs intégrations. Ça craint qu'il nécessite OpenGL pour fonctionner.

Eh bien, ma carte l'a soutenu, alors je l'ai mis dans XD. Mais comme ça, pour le travail, je ne suis jamais à court. Fondamentalement illimité. Mais ça marche encore lentement dans Cinnamon !!

@zenfulcoder Bienvenue là où se trouve le goulot d'étranglement. Ce n'est correctement pas à cause de la taille de votre mémoire, mais cela pourrait être la vitesse / latence de la mémoire, etc. Et le reste du PC (disques / carte mère / hm .. etc.).

Néanmoins, ce n'est probablement pas du tout lié à vos spécifications, comme vous pouvez le voir dans la section ci-dessus. Il y a un bug dans les pilotes vidéo, Xorg ou quelque chose dans ce domaine.

@ danger89 c'est définitivement un problème avec Cinnamon. J'ai lu que la v4 était peut-être meilleure, mais elle n'est pas encore assez stable pour Debian.

Cette page vous a été utile?
0 / 5 - 0 notes