Cinnamon: Задержка перерисовки окна при перетаскивании окон

Ненавижу говорить «я тоже», но ... «Я тоже!» Я работаю на несколько более старом компьютере, а Cinnamon работает поверх Ubuntu 13.04. Все остальное вроде нормально, проблема только в перетаскивании окна. И заметно "заикание", после которого окно просто перескакивает на следующую точку. Вроде происходит при перетаскивании любого окна (хром, uxterm). Дайте мне знать, какую еще вспомогательную информацию я могу предоставить. Я не могу найти ничего интересного в своих системных журналах.

Я могу это подтвердить, но у меня очень плохая видеокарта ...

Я тоже испытываю те же проблемы. Я использую последнюю версию Cinnamon из ночного ppa на Ubuntu 13.10.

Я запускаю систему с несколькими головками на Arch Linux с Cinnamon 2.0.2 в настоящее время (3x 1920x1080). Я пробовал и 660, и мой 7870. Они оба демонстрируют одинаковое поведение, чрезвычайно запаздывающие окна при перемещении или изменении размера. Я использую атм с драйверами с открытым исходным кодом. (Попробую катализатор, как только они обновятся, чтобы работать)

В моей системе это почти невыносимо.

--- Обновление --- если я отключу в панели настроек Cinnamon -> Плитка окон и переворот краев -> Плитка окон и привязка - окна снова быстро перемещаются по экрану; Я получил эту подсказку, перемещаясь вокруг окна, и у меня появился новый HUD, показывающий мне позицию, в которую я мог бы поместить это окно; всякий раз, когда появлялся HUD, запускается задержка.

Я могу подтвердить то же поведение на своем ноутбуке; с использованием Manjaro Linux и Cinnamon 2.0.6
У меня двухъядерный процессор P6100 и видеокарта Intel HD 3000.
У меня раньше не было этой проблемы с 1.6 или 1.8.
Я искал вариант с Muffin для отключения «содержимого окна» при перемещении, но пока безуспешно, используя редактор Dconf.
Было бы здорово, если бы кто-нибудь объяснил, почему это происходит.
Продолжайте хорошую работу ;)!

Задержка при перетаскивании окон ничто по сравнению с изменением размера окон (например: gnome-terminal), это может занять несколько секунд :-(

Я подтверждаю эту ошибку с Intel Core I5 ​​и графическим контроллером Intel (2-го поколения).

Вы можете установить порог тайлового HUD на 1, и это по существу отключит отображение HUD, но при этом тайлинг останется включенным. Возможно, в следующей версии будет добавлен более прямой способ его отключения, а также более надежный набор графики для анимации HUD.

Я могу подтвердить эту ошибку на процессоре i7-2600K и графическом процессоре AMD R9 290 (последние бета-версии драйверов). Особенно на моем экране с частотой 120 Гц. Отключение тайлинга и привязки не помогло.

Какую версию Cinnamon вы используете? Одна из причин этого была исправлена ​​относительно недавно.

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

Я использую Cinnamon 2.0.14. Постараюсь установить последнюю.

Возможно, важнее иметь последний кекс. Если вы используете маффин 2.0.4, у вас еще нет исправления. Если вы запустите 2.0.5, она будет.

(Я не гарантирую, что ваша конкретная проблема будет исправлена, возможно, другая причина, но это стоит проверить)

Я испытываю нечто подобное с Cinnamon 2.0.14 и Muffin 2.0.5 на Mint 16 с i5-4440s с графикой Intel HD 4600. Когда я перетаскиваю Windows, они не успевают за курсором мыши. Как будто окна прикреплены к моему курсору маленькой резинкой.

Вот видео о том, что я переживаю. Это нормальное поведение? http://youtu.be/KylzMTZpD7w

Я могу подтвердить, что этот случай все еще актуален для Cinnamon 2.2.14, а также для Gnome Shell 3.12.2 на Debian Jessie.

Я тоже это понимаю, и, честно говоря, это действительно отвлекает. Заметно менее гладко, чем Unity и т. Д., Да и Windows ...

Испытал то же самое, на которое я жаловался ранее, но также с NVidia GTX 760. Проблема определенно хуже с несколькими мониторами.

Я также получаю это на Cinnamon 2.2.14 с NVidia GT 630 с проприетарным драйвером версии 340.24 (и двумя мониторами). При переходе на версию драйвера 304 окна снова быстро перемещаются, но затем возникают разрывы.

10 августа 2014 г., 4:04:47 AM EEST, Андрес Манц написал:

Я получил это и на Cinnamon 2.2.14, с NVidia GT 630 с
проприетарный драйвер версии 340.24 (и два монитора). При понижении
до версии драйвера 304 окна снова перемещаются быстро, но затем я
опыт разрывания.

Задержка перетаскивания окна исчезает, когда vsync отключен через
переменные среды. Драйвер AFAIK Nvidia 304 не включает vsync по
по умолчанию (в отличие от более новых), поэтому это может объяснить, почему у вас быстрый
перетаскивание при переходе на нее.

Однако высокая загрузка ЦП распространена независимо от vsync.

Могу подтвердить, что окна намного менее лагают, если я не пытаюсь включить vsync (драйверы Intel), но тогда видео невозможно смотреть.

Также странно, что у linux mint нет этой ошибки, а у arch linux есть.

@startas Нет, получаю на Mint 17.

Еще более странно с тех пор, как я написал в этом выпуске, у меня больше не было этой проблемы. С тех пор я установил Cinnamon на нескольких различных устройствах, конфигурациях оборудования и программного обеспечения (дистрибутивов).

Это странно - я "решил" эту проблему (у меня только графика Intel HD, поэтому она может работать только для графики Intel), перекомпилировав xf86-video-intel с флагом "--disable-dri3" и перекомпилировав lib32-mesa с тем же флаг "--disable-dri3", конечно, вы также должны удалить флаг "--enable-dri3".
Хотя я использую 64-битный Linux, компилируя 64-битный пакет mesa без dri3 и устанавливаю его, вылетает рабочий стол cinnamon, но каким-то образом перекомпиляция только xf86-video-intel и 32-битной версии mesa для 64-битных систем «устранила эту проблему», она также исправлены огромные лаги в хроме.
Отключение только dri3 в 2d-драйверах не работает, но отключение dri3 в 32-битной версии mesa и его установка сработали, интересно, почему - этот пакет даже не установлен по умолчанию, поскольку 64-битный Linux использует 64-битную корицу, поэтому он использует 64-битную меза, и я понятия не имею, как это работало: D

за исключением того, что есть одна проблема, DRI3 не существовало, когда эта проблема была впервые создана.

Думаю, в настоящее время Arch Linux также по умолчанию отключает DRI3?

Кажется, эта проблема может быть связана с чем-то, что я вижу в программе Kerbal Space для Linux (с Cinnamon): идеальные фреймворки, за исключением случаев, когда я щелкаю и удерживаю мышь, чтобы перемещаться вокруг ракеты - тогда она заикается и плохо прыгает. Cinnamon, возможно, блокирует цикл перерисовки для событий мыши?

В arch linux xf86-video-intel компилируется без dri3, но mesa компилируется с dri3.

на моем довольно быстром компьютере изменение размера окон с помощью корицы - это боль, и мне бы очень хотелось отключить визуализацию содержимого окна в реальном времени. xfce делает это очень хорошо.

Это происходит, но только на моем внешнем мониторе, на Macbook («конец 2014 года») с графикой Intel. В окне также будут отображаться артефакты разрыва, опять же только на внешнем дисплее. При включении «TearFree» задержка не меняется заметно, но разрывы исправляются. Я масштабирую внешний дисплей до 2x2 с помощью xrandr.

edit: Я должен отметить, что что-то вроде glxgears не страдает от снижения частоты кадров, если я перетаскиваю его на этот дисплей, на самом деле он сообщал ~ 71 кадр / с на мониторе с частотой 60 Гц, несмотря на то, что движение заставляло его выглядеть <10 кадров в секунду. Если оставить его в покое, он работает нормально.

edit2: похоже, что масштабирование тоже не меняет лаг.

@wrouesnel и другие ...

Проблема с KSP, вероятно, связана с слишком высокой частотой опроса вашей мыши, особенно если у вас есть игровая мышь, такая как Razer DeathAdder или аналогичная (которую я использую). Следующий учебник должен помочь:

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

Я записал видео, показывающее мою проблему (проблема с перетаскиванием браузера Chromium, в то время как Nemo и Firefox запускаются только для сравнения): https://youtu.be/Ec99EYjwiqY
У меня такая же проблема с IntellJ и иногда с Pidgin или реже с Nemo. Я использую Mint 17.3 и Cinnamon 2.8.6 с пропиетарными драйверами AMD. На заметку:

-Мята 17.3 с корицей 2.8.6
-не удалось загрузить драйверы gpu с открытым исходным кодом для их тестирования, теперь он держал меня в режиме программного рендеринга (я помню, что xorg с открытым исходным кодом работал нормально, когда я установил 17.0 Mint назад несколько месяцев назад)
-Принудительное отключение vsync в amd propietary CCC помогает немного меньше тормозить окна, но делает разрывы экрана особенно при прокрутке веб-сайтов
-Когда Cinnamon только запустился, все работает нормально, без лагов перетаскивания окон, без медленного изменения размера. Проблема появляется через некоторое время (например, через 10-40 минут после запуска Chromium).
-Перезапуск Cinnamon (ctrl + alt + esc) помогает временно (выше точки)
- (править): этого не было раньше на 17.2 и Cinnamon 2.6, если я правильно помню, но тогда у меня была большая проблема с разрывом.

Редактировать:
То же самое происходит с драйверами с открытым исходным кодом, удалось их переустановить.

Запуск свежего Mint 17.3 Cinnamon с USB-накопителя, та же проблема, что описана выше.
Для сравнения проверил Ubuntu Gnome3 и Ubuntu Mate. При длительной работе обоих с USB-накопителей проблем / замедлений не замечено.

Похоже, что это связано с графическим процессором, особенно с программным обеспечением, поддерживающим графические процессоры, например Chromium.
Второе, на что следует обратить внимание, похоже, что это происходит быстрее, если у вас есть Intelihide для строки меню и продолжает пробивать строку меню с окном Chromium. Я слышу, как вентиляторы в ноутбуке начинают работать громче. Лучше всего перетаскивать окно Chromium, перемещаясь по рабочему столу.

«Отключить создание для полноэкранных окон» включено / отключено - без изменений

Это медленно воспроизводится даже с перфорацией строки меню, самый простой способ - просто некоторое время просматривать Интернет, но я понимаю, что отладка может быть адом.

У меня тоже есть эта проблема, но я заметил, что через некоторое время окна становятся _laggy_, но если я открываю новые, они не _lag_.

Например, если я оставлю терминал там, скажем, на час, он будет немного заикаться при перетаскивании, но только что открытый терминал будет вести себя нормально.

И да, это когда у меня открыт хром (который в основном открыт все время).

В этом нет ничего страшного, так как все остальные аспекты, похоже, работают нормально (например, вы не замечаете большего отставания в играх или что-то в этом роде) - единственная другая странная вещь, которую я заметил, это то, что экран блокировки занимает около 10 секунд. для загрузки (никогда не замечал, что до перехода на Mint 17.3)

PS: Я заметил, что процесс cinnamon --replace будет показывать довольно высокую загрузку ЦП (около 16% в моей системе) через некоторое время после того, как я переместил окно _laggy_.

Отключен intellihide, панель всегда отображается. Запускаем ОС на несколько часов и сюрприз! никаких лагов! Я просто чувствую себя на небесах.

Я могу подтвердить отставание окна от курсора в Linux Mint 17.3, Cinnamon 2.8.6 с проприетарным драйвером nvidia 352.63. Очень надоедливый! Проблема не зависит от того, включен композитинг или нет!

Я также могу подтвердить отставание с Mint 17.3, Cinnamon 2.8.6 и интегрированной графикой i5-4210U или nVidea GeForce 820M.
Я немного поигрался с настройками отображения / скрытия панели, и оказалось, что отставание есть только тогда, когда панель отображается. Когда я установил автоматическое скрытие, все окна перетаскиваются плавно.
(Да, я знаю, что это полная противоположность комментария от DarekDeo).

Может быть, не полная противоположность, из обоих наших комментариев похоже, что с панелью что-то не так. :)

изменить: или, по крайней мере, связаны с ним.

У меня тоже есть эта проблема. Кто-нибудь пробовал другой графический драйвер? У меня была эта проблема на Xubuntu 15.10, и как только я сменил драйвер, все заработало. Кажется, я не могу найти здесь такой вариант? Я перехожу к драйверам на панели настроек, и появляется пустой список.

Установка: проприетарные драйверы Fedora 23, Cinnamon, GDM, Nvidia (также с Nouveau)

Я также испытываю заикание при перетаскивании окон, а также при наборе текста или при прокрутке файла в Vim. Например, пока я печатаю, при нажатии клавиши появляются несколько букв, затем курсор висит на несколько миллисекунд, а затем появляются буквы, которые я набрал во время зависания.

Кажется, что заикание происходит регулярно. Если бы мне пришлось угадывать, я бы сказал примерно каждые 500 мс. Интересно, что если я быстро перемещаю окно в течение определенного периода времени, вверху отображается, что Xorg иногда забирает огромный процент ресурсов ЦП (~ 53%) при перемещении окон ... это кажется неправильным. Есть идеи?

РЕДАКТИРОВАТЬ: я загрузил Fedora 23 Cinnamon Spin Live CD и, что интересно, не обнаружил заикания. Но при использовании той же среды DM (драйверы Cinnamon, lightdm, nouveau) в моей установке жесткого диска все еще работает. Я могу попробовать установить спин Cinnamon прямо с Live CD на другом компьютере, чтобы проверить, сохраняется ли проблема; Я сообщу о любых результатах.

Вау, ладно. Спасибо @DarekDeo, это работает намного лучше, когда интеллектуальная панель отключена. Просто жаль, что я не могу смотреть видео Youtube в большом плеере, когда мой браузер сейчас работает в полноэкранном режиме, поэтому я включил эту панель в первую очередь, но окна становились плохими.

Мне кажется странным, насколько отстают все окна, хотя они не невыносимы, но если я вернусь к Windows, мои 144 Гц заставят все выглядеть и чувствовать себя так гладко, перемещая окна, и все они кажутся такими прочными и стабильными, вернитесь Linux и мой 60 почти кажутся более плавными, чем мои 144, и кажется, что окнам нужно тормозить, когда вы их тащите.

Я также просто хочу добавить, что интеллектуальная панель, похоже, также влияет на окна, мой браузер мигал белым, часто глючил, несколько раз пробовал их, чтобы увидеть, какой из них больше не испытывал этого, подумал, что что-то может быть сломан корицей или моим графическим драйвером, оказывается, проблема в панели @ _ @

Что ж, это интересно, я заметил, что заикание, которое я видел, казалось, происходило с той же частотой, что и апплет системного монитора, поэтому я удалил его с панели и перезагрузился, и теперь заикание у меня исчезло. Похоже, это еще больше подтверждает предположение @DarekDeo о том, что с панелью что-то не так. Может быть, какой-либо процесс / объект обновляет, он ненадолго зависает во время цикла перерисовки (я не программист графики)?

На самом деле у меня такая же проблема, обновление до более новой версии Cinnamon сделало его немного лучше, но мой рабочий стол Nvidia (i5-3570k, Nvidia 780ti) все еще не такой гладкий, как мой гораздо менее мощный графический ноутбук Intel (i7-4500u, Intel графика 4400).

Оба они работают под управлением Mint 17.3, Cinnamon 3.04 (ночной канал) и ядра 4.4.0-22.

Используются драйверы Nvidia 364 (364.19-0ubuntu0 ~ gpu14.04.3) из PPA драйверов Nvidia и драйверы Intel, включенные в ядро.

@ davidva-cml спасибо, удаление апплета Sytem Monitor решило для меня проблему!

Отключена "синхронизация с vblank" в настройках nvidia xserver, и изменение размера приложений, таких как Telegram, теперь выполняется плавно.

Для меня это все еще проблема.
Я использую новую установку Ubuntu 16.04.1, использую Nvidia GTX 1070 с версией драйвера 375, поэтому производительность не должна быть проблемой.

@JosephMcc , можем ли мы отметить эту проблему как ошибку?

@ davidva-cml Удалось починить? Я также вижу, что Xorg поверх использования ЦП при перетаскивании окон ... Возможно, нам следует сообщить об этом как о проблеме Xorg. Хотя, в конце концов, это всегда может быть проблема с Cinnamon ... Самый простой способ воспроизвести это - запустить glxgears в фоновом режиме, перетаскивая окна.

Однако некоторые люди в этой проблеме могут страдать от совершенно другой проблемы с задержкой (которая может быть связана с Cinnamon).

Боюсь, что у меня такая же проблема. Но у меня действительно мощный ПК (Core i7-5930K 3,5 ГГц, 6 ядер + Nvidia TITAN X с последним драйвером nvidia + 32 ГБ ОЗУ и мои ОС, установленные на SSD). Так что выступления не должны быть проблемой. Но все же каждый раз, когда я пытаюсь перетащить окно, у меня, как и у всех в этой ветке, наблюдается медлительность. Но чем больше у меня открытых приложений, тем медленнее!
Когда я отслеживаю (htop), я вижу, что процесс Xorg использует 90% или более загрузки ЦП. Значит, это могло исходить от Xorg, а не напрямую.
Было бы здорово получить обратную связь, чтобы понять, что там происходит.
Благодарю.

Бег :
Ядро Linux 4.10.0-generic
FerenOS (в котором используется последняя версия дистрибутива Linux Mint)
Бегущая корица 3.4.6

Мне любопытно, придумали ли другие способы обхода этого в последнее время, поскольку это затихло.

Для меня Cinnamon начинает дестабилизировать с этой задержкой, растущей от перезагрузки с течением времени, до тех пор, пока она не становится слишком раздражающей, и обычно я обнаруживаю, что мне нужно сильно перезагружать ее, так как экран больше не просыпается от сна. Как и в предыдущем посте, это мощный компьютер (20 ядер, 40 потоков, двойной xeon, 128 ГБ оперативной памяти, nvidia 1070, двойной nvme, 3x 4k дисплеи), поэтому производительность не является проблемой, и я не получаю этого с другим настольным компьютером. окружения, отличные от kde (у которого есть собственные проблемы с компоновкой). Я отключил vblank и большинство других функций gl, и все еще дестабилизируется, обычно в течение недели, но никогда не было никаких ошибок, которые могли бы что-то сказать.

Я использую драйверы Arch linux, Cinnamon 3.8.1-1, 4.16.13 и nvidia 396.24. Я продолжаю обновляться, надеясь, что это уйдет, но никогда этого не происходит.

По-видимому (как и в случае с большинством всех настольных компьютеров сейчас) ответ - просто использовать программный рендеринг рабочего стола. В прошлый раз мне удалось пройти несколько недель, прежде чем я получал 5-секундный тайм-аут отображения примерно каждую минуту или около того, что со временем становится довольно раздражающим.

Обычно я просто переключаюсь на другой рабочий стол, KDE (молюсь, чтобы они его тоже исправили) или Mate (Марко имеет тенденцию вести себя, но в остальном рабочий стол отсутствует по сравнению с другими) после pacman -Syyu, но на этот раз я заметил программный рендеринг корицы Режим. После недели обычного использования с программным рендерингом я обычно начинаю получать задержку через несколько дней, но с программным режимом все прошло гладко и действительно не вижу недостатков в производительности при использовании настольных компьютеров.

Жаль, что эта ошибка композитора, кажется, сохраняется, но почти наверняка связана с видео / gl. Композиторы - это проклятие каждого рабочего стола Linux, которое я нахожу, я еще не нашел ни одного, который работал бы должным образом, даже windoze aero, который я нашел в 4k, - это абсолютная чушь, которая поставляется с моим xps 9560.

Хороший обходной путь - добавить CLUTTER_VBLANK=none в / etc / environment и включить конвейер принудительной композиции на всех мониторах в настройках nvidia в разделе «Конфигурация дисплея» -> «Дополнительно». Это перемещает обработку vsync от композитора к драйверу, а также помогает на amdgpu с включенным TearFree в конфигурации xorg.

Спасибо за это, я установил в своей / etc / environment, но я не обнаружил необходимости пробовать версию с аппаратным рендерингом, так как это только, кажется, вызывает драму и хаос. Я очень доволен версией с программным рендерингом, некоторыми задержками отрисовки в cairo-dock и некоторых других приложениях, но не так сильно, как аппаратная версия, которая гадит сама по себе.

Интересно, что даже в программном режиме у меня такая же задержка, но гораздо медленнее, чем при рендеринге с полным графическим процессором. Похоже на какую-то утечку ресурсов, но если не прямой рендеринг против графического процессора, я предполагаю некоторую ошибку в управлении ресурсами на рабочем столе.

Какие полезные отзывы, журналы, отладки и т. Д. Помогут исправить это? Я нигде не вижу ничего ненормального, кроме того, что рабочий стол сходит с ума через случайные / обычные интервалы.

Также, чтобы прояснить, я думаю, что во многом это связано с высоким разрешением, в котором я это использую. Мой рабочий стол работает с разрешением 11520x2160 (3x4k дисплея), что накладывает нагрузку на любой рабочий стол, который, как я обнаружил, даже пытается ускорить GPU. Я не думаю, что кто-то влияет на такие вещи, но с появлением 4k, 5k, а теперь и 8k борьба реальна. Вот почему композитинг, похоже, не работает на любом рабочем столе, включая unity, kde, cinnamon или даже mate / marco с прямым рендерингом против gpu в этом масштабе.

Следует отметить, что масштаб разрешения для правильного составного рендеринга был проблемой с ~ 2010 года, когда я запускал 6x 1080p дисплеи под Linux с появлением композитинга.

Итак, я снова вернулся, чтобы проверить это, после недавних 5-секундных задержек перерисовки окна при программном композитинге после примерно 80 дней безотказной работы я снова обновился, чтобы увидеть, что было нового и, надеюсь, улучшилось. Короче говоря: не так уж и много.

Теперь на ядре 4.0.7 пакеты cinnamon, и запуск с программным рендерингом, как и раньше, был ужасным с ужасным мерцанием и странными проблемами обновления вокруг частей окон (например, кнопок свертывания / выхода). Пробуя аппаратный режим, он работает без этого, но почти сразу я начал получать задержку обновления в течение нескольких дней использования, которая неуклонно растет, как и раньше с аппаратным режимом, который заставил меня использовать программное обеспечение. Программное обеспечение в 4.0 пока что кажется бесполезным, но аппаратный рендеринг все еще имеет эту проблему уже много лет.

Что нужно сделать, чтобы это исправить? Разрешение дисплеев не становится меньше, и эти композиторы не могут справиться ни с чем, кроме старых разрешений HD.

@mikebutash Программный режим рендеринга никогда не предназначался для использования, пока загружен графический драйвер. Это для режима VGA.

Для 4.2 открыт ассортимент PR. Если вы чувствуете себя комфортно, тестируя их, вы можете проверить мои ветки PR в репозитории Muffin. Другой вариант - отключить vsync в Настройках -> Общие и включить конвейер принудительной композиции в настройках nvidia. Больше ничего нельзя сделать, чтобы исправить это для серии 4.0.x.

Изменить: также см. Эту страницу вики .

@jaszhix , согласен, что это не значит быть решением, но кое-что говорит, что он работает лучше, чем предпочтительный аппаратный метод, особенно со временем. Однако не так много в более новой версии 4.0, еще один регресс с мерцанием и экстремальной задержкой, и сразу же нарастающее отставание снова началось на оборудовании. Тот факт, что со временем ситуация ухудшается, показывает нестабильность кода, что было с ранней версии 3.x и, вероятно, до сих пор в вашей версии 4.2, поэтому я сомневаюсь, что это имеет значение, на какой версии я на самом деле работаю.

Раньше я выполнял как vsync, так и принудительный конвейер по рекомендации, но прямо сейчас заметил, что конвейер принудительной полной композиции был снова отключен в настройках nvidia, поэтому повторно включите и посмотрим, как это работает. Я уже по-прежнему вижу периодические задержки после включения его на всех дисплеях, хотя остается посмотреть, как, если ситуация будет неуклонно ухудшаться, как это имеет место.

Если все DE настолько одержимы композитингом, было бы неплохо, если бы они обеспечивали стабильность разрешения при масштабировании, поскольку все они в основном страдают от одних и тех же проблем при больших разрешениях. Корица в моем случае действует как утечка памяти, до перезагрузки / обновления через 90 дней или около того, я бы увидел, что cinnamon-desktop обычно использует 80-90% процессора в процессе верхнего говорящего в htop (похоже, нить ну по сути, так как у меня есть 39 других потоков, которые он мог бы использовать) и использовал много памяти, около 20-30 ГБ (что-то, что нужно сказать, имея 128 ГБ в этой системе). Должен быть способ протестировать это в масштабе, и, казалось бы, какое-то стресс-тестирование, подобное valgrid. После 90 дней использования корица всегда готова к взлому, и это в программном рендере. Обычно он умирает в аппаратном обеспечении в течение недели. KDE страдает примерно так же.

Большинство людей обычно не используют дисплеи с разрешением 11200x2160 пикселей, это всего лишь 3 дисплея с разрешением 4k, которые с каждым днем ​​становятся все более распространенными и дешевыми, или подстраиваются под себя соответственно. В какой-то момент при компостировании необходимо учитывать такие решения, как это, и более высокие, с долгосрочной стабильностью, или найти метод компромисса, который лучше подходит для масс. Лучше иметь стабильные перерисовки на моих окнах, чем колебания / прозрачность для них с течением времени. Если бы я знал, что дестабилизирует мою систему, я бы с радостью отключил ее.

Какая у вас версия драйвера Nvidia? Если вы используете 390 или 396, используйте 415.25 в Ubuntu PPA .

Комбинированное разрешение моих мониторов составляет 8560x1440, и я не вижу какого-либо замедления работы с Cinnamon с течением времени в моих PR-ветках, в те несколько периодов, когда я не перезапускаю Cinnamon для разработки.

Конвейер композиции силы добавляет некоторую задержку. Я обычно не рекомендую его использовать, и если вы видите проблемы с vsync Cinnamon, убедитесь, что в настройках nvidia включен параметр «Разрешить переворачивание», а параметр «Синхронизировать с vblank» отключен. Не используйте какие-либо обходные пути драйверов, предназначенные для версий 3.8 и старше.

Мне непонятно, что вы считаете задержкой - курсор не синхронизируется с окном при перетаскивании? Или общая задержка ввода окон? На эти вещи влияют разные части кода композитора. https://github.com/linuxmint/muffin/pull/397 улучшает оба, а https://github.com/linuxmint/muffin/pull/392 улучшает последнее - что я бы хотел перейти в 4.0, но он нужно больше тестирования.

еще одна регрессия с мерцанием и экстремальной задержкой

Давайте рассмотрим эти проблемы отдельно, уже есть пара проблем, связанных с мерцанием, и я не заметил, чтобы в 4.0 было хуже. Конечно, это нужно исправить, но сложно исправить то, что нельзя надежно воспроизвести.

Итак, на момент последнего обновления я использую nvidia 415.25-4, что соответствует вашим ожиданиям.

Я установил разрешить включение (ранее не выполнялось), отключение синхронизации с vblank (обычно выполняется) и принудительный полный конвейер композитинга на каждом дисплее (сброс этого времени проверки).

Лаг, как и все, что я делаю. Если я щелкаю между окнами, перерисовка приводит к некоторой задержке, когда экран останавливается на несколько секунд, застывая на месте. Недавно я играл в Overlord в Steam, и он делает это, что довольно раздражает во время боя. Я научился замечать и упреждать, когда это происходит. Использование рабочего стола также приводит к этому срыву, ввод текста приводит к различным задержкам / заиканиям при нажатии между окнами и во время набора текста. Все останавливается на секунду или две во время набора текста или любой активности мыши или клавиатуры случайным образом.

Перетаскивание вещей имеет тенденцию усугублять проблему, большинство вещей пользовательского интерфейса имеют тенденцию раздражать и отставать от рабочего стола, визуально задерживая работу на секунду или две. Перенесемся на 90 дней вперед, и это приводит к 5-секундному срыву всего, что вы делаете, когда он решает ударить, что происходит каждые несколько минут, а иногда и реже.

Что касается мерцания, я заметил, что это происходит на всех дисплеях, случайным образом в определенных областях, не всегда одинаковых, но как в какой-то призрачной области прошлого, которая начнет мигать на несколько секунд и исчезнет. Это касается всех 3 дисплеев в формате 4k, некоторых небольших подмножеств по одному.

Это еще один артефакт программного рендеринга, кажется, но странно, когда это происходит. Я не видел этого при аппаратном рендеринге, но за последние 90 дней много работал с программным обеспечением, используя это. Достаточно плохо с точки зрения оборудования, без каких-либо странностей в программном обеспечении.

Я установил разрешить включение (ранее не выполнялось), отключение синхронизации с vblank (обычно выполняется) и принудительный полный конвейер композитинга на каждом дисплее (сброс этого времени проверки).

По сути, я предлагал повторно включить vsync маффина в меню «Настройки» -> «Общие» и отключить конвейер принудительной полной композиции. Вы столкнетесь с наибольшей задержкой, если оба будут включены.

Мерцание определенно хуже при программном рендеринге и при использовании определенных переменных окружения Clutter, которые используются, когда он включен. Я не видел, чтобы это происходило при загрузке с параметром nomodeset , но мерцание будет происходить, если драйвер Nvidia загружен, а Cinnamon использует программный рендеринг. См. № 7985.

Поведение "зависания" звучит так, будто поток периодически блокируется. Используете ли вы сторонние апплеты / десклеты / расширения? Проверить с помощью gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions .

Я получил, не уверен, насколько это больно под аркой, если честно, иначе я обычно не в себе. Я обычно бегаю с их релизами, обновляю и немного молюсь, чтобы проблема просто исчезла. Однако сейчас не в основных версиях, с 3.x до 4.0. Я стараюсь не сильно отклоняться, я зарабатываю на жизнь этой системой, включая различные vpns, виртуальные машины и различные другие точки интеграции, которые я использую.

Я не получаю мерцания под оборудованием, хотя при загрузке оно дает случайную задержку почти сразу. Я могу сказать, что уже становится хуже.

Да, мне снова пришлось прекратить использовать Cinnamon, задержки при перерисовке окон убивали меня всего через несколько дней, задерживаясь до 5 секунд в любом обновлении окна, которое я активно использовал. Попытаться поиграть с этим невозможно. Обычно я возвращаюсь к программному рендерингу, где обычно требуются месяцы, чтобы добиться таких же длительных задержек в обновлениях, но программный рендеринг теперь в 4.0 совершенно непригоден.

В скором времени KDE / Kwin по-прежнему остается бесполезным, почти такая же проблема, но я просто никогда не заставлю окно обновляться, мне придется свернуть и повторно выбрать окно, чтобы перерисовать его с любыми изменениями.

Почему это действительно так сложно для композиторов в разных DE?

Я действительно проверял сторонние расширения, и нет, все, что у меня было, это расширения корицы, и в основном стандартные. Я обычно накладывал cairo-dock и использовал его для нестандартных вещей.

Я потратил много времени, наблюдая за htop, iotop, nvtop и powertop, и другими, пытаясь понять, почему это происходит, но я никогда не видел, чтобы что-то особенно отображалось как ресурсная свинья, кроме cinnamon-desktop сам и xorg со временем.

Здесь, конечно, всегда становится нечетко, насколько плохо себя ведут xorg, драйверы nvidia или cinnamon? Я не знаю хороших способов их внутренней отладки. Я открыт для слуха, если вы знаете хороший способ наблюдать за внутренними компонентами этих продуктов на предмет проблем, особенно с самой корицей, поскольку со временем она определенно становится ресурсоемкой.

Приложения делают свое дело, только окно не перерисовывается в те моменты "задержки", поэтому я согласен, что что-то блокируется, но я не могу понять, что это такое.

Мне действительно пришлось переключиться на kde, так как задержка вызвала много проблем, чтобы наконец использовать, но kde не выглядит чемпионом, поэтому готов снова попробовать корицу. Mint почти слишком прост, я терпеть не могу gnome3, особенно его дисфункциональную версию ubuntu, поэтому я продолжаю возвращаться к корице, несмотря на проблемы. Я бы очень хотел помочь исправить их, если это возможно, так как очевидно, что я не единственный в этой теме.

Мне немного любопытно, что случилось с другими людьми, увидевшими это ...

Почему это действительно так сложно для композиторов в разных DE?

Оптимизировать композитинг сложно, и требуется много проб и ошибок. Работать над этим просто непросто.

все, что у меня было, это расширения корицы, и в основном стандартные. Я обычно накладывал cairo-dock и использовал его для нестандартных вещей.

Главным образом? Какие расширения используются? Это важная деталь. Нам нужна информация, которая поможет воспроизвести проблему, а не стена текстов о композитинге. Благодаря!

Был один рабочий стол, который казался включенным, bbcwx, апплет погоды, но я не видел никаких признаков его присутствия или работы ранее.

[ user @ host ~] $ gsettings получает applets с поддержкой 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 ' , ' панель1: справа: 8: [email protected] : 12', ' панель1: справа: 9: [email protected] : 13', ' панель1: справа: 10: [email protected] : 14 ']
[ user @ host ~] $ gsettings получает org.cinnamon enabled-desklets
[' [email protected] : 1: 50: 50']
[ user @ host ~] $ gsettings получает org.cinnamon enabled-extensions @ как []

Я действительно понимаю, что работа с композитингом - сложная работа, поэтому я не хочу преуменьшать усилия, и я, конечно, в глубине души ценю их, но композитинг есть в каждом DE, я использую самое слабое звено во всем, что находится под Linux. Даже в Windoze Aero может быть корзиной для композитинга, которую я обнаружил в своем ограниченном использовании из коробки на ноутбуке dell. Удивительно, сколько уникальных усилий, кажется, делают это неправильно, поэтому я просто задаюсь вопросом, почему это так необходимо, когда, казалось бы, невозможно выполнить достаточно хорошо. Кажется, должен быть способ получше.

А, ладно, если bbcwx включен, но не отображается, это может быть некорректно. Я также открыл несколько PR, предназначенных для 4.0.x, которые могут повлиять на производительность, например # 8180. Я не уверен, когда он будет объединен, но все должны его использовать или переключиться на GWL.

Я понимаю разочарование - именно поэтому я начал изучать C, чтобы улучшить маффин, но я мало что могу сделать, кроме открытых PR (что я и делал). Графика в Linux в целом давно отстала и совсем недавно начала подтягиваться после некоторых больших изменений (например, протона). Надо еще много поработать, и моя цель - сделать маффин таким же отзывчивым, как DWM в Windows 10.

Я даже не совсем помню, как включал его, так что должно быть было что-то случайное и забытое. Сниму, если разберусь как.

Я использую Linux с 2006 года на постоянной основе, и помню, до / после композитинга, и раньше жизнь была намного проще. Я имел дело с проблемами Ubuntu и Compiz в течение многих лет, когда это началось, это привело меня к KDE, позже к Mate / Cinnamon, а теперь взад и вперед в последнее время, что когда-либо было меньше отстой.

До сих пор переход с 3.x на 4.0 был худшим для Cinnamon, но kwin, compiz, mutter, похоже, все они страдают от некоторой внутренней утечки ресурсов, которая со временем только ухудшается. Поскольку все они это делают, я часто подозреваю, что это компонент более низкого уровня, такой как драйвер xorg или nvidia, который вызывает дестабилизацию среди всех DE, но на самом деле это невозможно сказать. Таким образом, я начинаю с DE, но я также смотрю различные * топы, чтобы попытаться выяснить, что вызывает эти графические задержки, но пока безрезультатно.

Я, как правило, следую за обычными обновлениями pacman Arch, чтобы попытаться получить обновления за пределами этого чисто, не зная, как попробовать следующие выпуски маффинов в Arch, иначе я бы.

У меня тоже есть эта проблема. Смотрите на скриншот для моих спецификаций. У меня даже ОЗУ 128 ГБ: https://gyazo.com/1f0443df15097949a2314bebba6d12db

Решил мой переход на XFCE> <(поэтому он не решен в Cinnamon)

@zenfulcoder Где, памяти ? Может быть, вам пора перейти на XFCE в вашем случае .. ха-ха

@ dangerous89 да, я люблю XFCE, я только что перешел на Cinnamon после многих лет работы с XFCE. Мне понравился Cinnamon для современного рабочего стола и их интеграции. Отстойно, что для работы требуется OpenGL.

Моя плата поддерживала это, поэтому я вставил его в XD. Но так я никогда не выбегу на работу. В основном безлимитный. Но в Cinnamon он все еще работает медленно !!

@zenfulcoder Добро пожаловать туда, где находится узкое место. Это правильно не из-за вашего размера памяти, но это может быть скорость / задержка памяти и что-то еще. И остальное ПК (диски / материнка / хм .. и т.д.).

Тем не менее, вероятно, это вообще не связано с вашими характеристиками, как вы можете видеть в предыдущем разделе. Есть какая-то ошибка в видеодрайверах, Xorg или что-то еще в этой области.

@ dangerous89 это определенно проблема с корицей. Я читал, что версия 4 может быть лучше, но она еще недостаточно стабильна для Debian.