Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В KDE включена поддержка тройной буферизации вывода на системах c GPU NVIDIA

27.06.2026 10:56 (MSK)

Опубликован очередной еженедельный отчёт о разработке KDE, в котором представлена порция изменений для ветки KDE Plasma 6.8, релиз которой запланирован на 14 октября. Наиболее заметным изменением стало включение поддержки тройной буферизации вывода на системах c GPU NVIDIA (Kwin автоматически включает тройную буферизацию, если видеокарта не успевает выполнить отрисовку). Ранее тройная буферизация была отключена из-за возникновения артефактов, причиной которых оказалась ошибка в коде синхронизации в композитном менеджере KWin. Теперь данная ошибка устранена и больше не замечено проблем, мешающих включению тройной буферизации.

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

Из изменений в ветке KDE Plasma 6.8 также отмечается появление вручную переключаемого режима слайдшоу для обоев рабочего стола (вместо автоматической смены обоев для перехода к следующему изображению нужно нажимать клавиатурную комбинацию или выбирать соответствующий пункт в контекстном меню). В редакторе меню kmenuedit убрано визуальное выделение настроек фреймами с другим фоновым цветом.

В ветке KDE Plasma 6.7 сформирован первый корректирующий релиз 6.7.1, в котором устранены зависания при подключении к ноутбукам с GPU NVIDIA и AMD дополнительных мониторов, а также аварийные завершения KWin при подключении мониторов через интерфейс DisplayLink и при блокировке экрана на системах с GPU NVIDIA.

Началась подготовка выпуска KDE Plasma 6.7.2, в котором повышена производительность полноэкранного отображений видео в приложениях на базе движка Chromium и улучшено выравнивание текста при древовидном режиме показа процессов в приложении System Monitor. Устранены проблемы, такие как аварийное завершение KWin при включении адаптивного изменения частоты обновления экрана (VRR, variable refresh rate) на системах с несколькими мониторами, нарушение работы RDP-сервера при использовании systemd и зависания приложений на движке Chromium при включении опции показа поверх других окон.

  1. Главная ссылка к новости (https://blogs.kde.org/2026/06/...)
  2. OpenNews: Недельный отчёт о разработке KDE
  3. OpenNews: Релиз среды рабочего стола KDE Plasma 6.7
  4. OpenNews: В KDE улучшена поддержка приложений на базе GTK 2 с тёмной темой оформления
  5. OpenNews: Размер кодовой базы KDE достиг 8 млн строк кода
  6. OpenNews: В KDE Plasma 6.8 решено прекратить поддержку X11
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65787-kde
Ключевые слова: kde
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (127) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:30, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Да, эти додики добавили переменную, специально для этого, чтобы пользователь мог включить тройную буферизацию (после исправления глитчей или обновления драйвера, к примеру) и захардкодили её игнорирование на nvidia.
     
  • 1.2, Аноним (2), 11:32, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Ну, здравствуй, желеобразная отрисовка.
     
     
  • 2.16, Аноним (16), 11:56, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –5 +/
    И еще Вялый постоянно включает 3д акселерацию. А в большинстве случаев и 2д не нужна.


     
     
  • 3.83, Аноним (-), 16:42, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Windows XP с VESA-драйвером не даст соврать, да.
     
  • 2.127, Alex (??), 13:23, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Оставьте этому челу вообще 1 кадр в буфере - пусть не мучается (раз не он понимает конвейерный принцип обработки).
     
     
  • 3.136, Аноним (136), 19:43, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Двойной хватает
     

  • 1.3, Аноним (1), 11:33, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Поломанные заголовки окон в 6.7.2 исправлять никто не собирается, я так понимаю.
     
     
  • 2.9, Аноним (9), 11:45, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Им еще OpenGl, отключать,
    Чтобы все на Vulkan.
     
     
  • 3.58, Аноним (58), 14:35, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И,м, е,щ,е, O,p,e,n,G,l, о,т,к,л,ю,ч,а,т,ь,
    > Ч,т,о,б,ы, в,с,е, н,а, V,u,l,k,a,n.

    зачем отключать? где об этом сказали разработчики?

    ps когда там от тебя пруфы на инпут лаг ждать? или ты совсем решил всех убедить в том, что ты врунишка?

     
  • 3.113, Zloy (ok), 06:11, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    при отрисовки на вулкане плазма со временем падает и приходится перезагружаться, так что хз. может эта буферизация это исправит.
     
  • 2.33, Константавр (ok), 12:40, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А что с ними не так? Не наблюдаю никаких проблем
     
     
  • 3.38, Аноним (1), 12:51, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А что с ними не так? Не наблюдаю никаких проблем

    Кнопка закрытия окна появляется только если развернуть окно на весь экран. Ещё при переключении рабочих столов фокус не возвращается. Допустим, у меня открыто окно с konsole на отдельном рабочем столе, и, понятно, мне нужен фокус на нём, когда я переключаю рабочий стол.

     
     
  • 4.42, Константавр (ok), 13:18, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Хм. Никаких проблем. АМДшная встройка. Может это энвидия онли фичур? :)
     
  • 4.57, Аноним (58), 14:33, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    с кнопкой зарытия проблем не наблюдаю никаких

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

     
  • 4.74, glebiao (ok), 16:21, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Подтверждаю.
    не кнопка закрытия, любая крайне правая кнопка (у меня крайне правая -- кнопка максимизации, очень естественная привычка) "съедается".
    Чтобы она стала нормально видна, нужно изменить размер окна (или свернуть - развернуть в заголовок).
    На KDE 5 такой фигни не было.
     
  • 3.109, Брату_перезвони_зайбал (?), 04:45, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С ним всё не так.
     

  • 1.4, Аноним (4), 11:35, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > тройная буферизация была отключена из-за возникновения артефактов, причиной которых оказалась ошибка в коде синхронизации в композитном менеджере KWin

    Это вейленд после 18 лет разработки :) Учимся переключать буфера.

     
     
  • 2.7, Xo (?), 11:42, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты 18 лет сидел на попе ровно и ничего не делал чтоб ускорить процесс. Но при этом хаваешь это за бесплатно.
     
     
  • 3.25, Аноним (4), 12:08, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У меня всё работает в Иксах и OpenGL. Если что, тройная буферизация - это изобретение прошлого века.
     
  • 3.46, выхухо (?), 13:36, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    бесплатно. прям как системду, ога.

    и, чсх, когда ойвэйлэнд-фэнбои крошат батон на иксы, то это, конечно, другое.

     
  • 3.116, dannyD (?), 08:47, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    а ты наверное ёрзал под клиентом.
     
  • 2.32, soarin (ok), 12:26, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Как будто это вообще нормально в десктопном линуксе работало

    Но можно так и без конца писать: иксопроблемы, KDE проблемы, GNOME проблемы, NVIDIA проблемы...

    Про весь десктопной линукс

    https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1269

     
     
  • 3.39, Аноним (16), 12:52, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В иксах это баг и его пофиксили. В КДЕ тройную буферизация сделали специально.
     

  • 1.6, Аноним (16), 11:38, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Ну вот, говорили они - в Иксах двойная буферизация, это плохо.
    Сделали тройную. И стало хорошо.
     
     
  • 2.8, Аноним (9), 11:44, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скоро Kde догонит Windows, по требованиям.
    Больше эффектов, больше Blur, Тройная буферизация, чтобы был смузи-интерфейс,
    Как там они называют сглаживание тормозов, а Желейный эффект,
    Это когда тормозит, но система себя замедляет, получается желейный эффект,
    И без артефактов.
    Стриммерам нужно показывать эффекты и красивый интерфейс,
    И для дизайнеров хорошо.
    Вот молодец то, а.
     
     
  • 3.59, Аноним (58), 14:37, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    линукс последние лет десять просит больше производительности по сравнению с вендой

    а еще инпут лаг там меньше

    или у тебя есть что сказать против?

     
     
  • 4.84, Аноним (84), 16:43, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >инпут лаг там меньше

    Таки да,
    Я на Linux, только из за Profile-Sync-Daemon.
    Типа Overlay-Fs.
    Все такое.
    Но ипут лаг, я решил у себя настройками Ос, Firefox, и Grub.
    Но честно говоря, до этого, думал что так и должно быть.

     
     
  • 5.124, Аноним (124), 13:12, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Но ипут лаг, я решил у себя настройками Ос, Firefox, и Grub.

    не, не решил

     
  • 2.70, Аноним (70), 15:30, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там немного другая двойная буферизация: приложение и композитор занимаются буферизацией раздельно друг от друга, и в результате ты получаешь не 2 буфера, а 4. С потенциальным тирингом из-за того, что оба два не смогли договориться о времени переключения буферов.
     
     
  • 3.134, Аноним (134), 17:56, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так либо у каждого приложения свой набор буферов, либо одно приложение, не успевающее вовремя заполнять свой единственный буфер, будет тормозить весь вывод на экран.
     

  • 1.10, Аноним (4), 11:49, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Второй абзац не отражает реальность. Тройная буферизация имеет профит только перед "двойной БЕЗ vsync". Если же программа не успевает рисовать в буфер, рывки будут и на тройной буферизации.
     
     
  • 2.12, Аноним (1), 11:54, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тройная буферизация вообще быстрее двойной, тут написано так, будто она вносит лаги вывода. Нет, если резервный буфер не отрисовался вовремя ты этого просто никак не заметишь.
     
     
  • 3.17, Аноним (4), 11:56, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Пояснение смотри ниже.
     
  • 2.13, Аноним (4), 11:55, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Пояснение: буфер 1 - отображается, буфер 2 - готов/ждёт, буфер 3 - туда прога рисует, долго рисует, вот подошла vsync - на вывод пошёл 2-ой буфер. Третий не готов, туда ещё рисуют, первый - устарел, и тут опять vsync - что пойдёт на вывод? В лучшем случае - фриз из 2-го, в худшем - дрыг назад из 1-го.
     
     
  • 3.24, Аноним (1), 12:05, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    При тройной буферизации следующий рисуется во 2 буфер пока 1 выводится на экран. Какие могут быть "дрыги назад"? Повторяется последний фрейм, если следующий не успевает рендериться.
     
     
  • 4.26, Аноним (4), 12:11, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ты забыл, что в тройной буферизации три буфера, а не два.

    > Какие могут быть "дрыги назад"?

    Вот такие: "тройная буферизация была отключена из-за возникновения артефактов, причиной которых оказалась ошибка в коде синхронизаци".

     
     
  • 5.52, Аноним (1), 13:59, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Назад ничего не рисуется, у тебя есть текущий и 2 следующих фрейма. 2 всегда готовы и 1 рисуется, если 1 готов и 1 рисуется получается двойная буферизация, если и она не успевает, ты видишь повторение последнего готового фрейма (вместо частично отрисованного фрейма поверх текущего). Показ старого кадра видео при переключении табов в том же браузере по-моему было связано с explicit sync и не буферизацией.
     
     
  • 6.129, Alex (??), 13:36, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе же уже по русски написали, что не всегда ДВА следующих готовы. Может быть готов только 1 из 2. Пример: не успел отрисоваться кадр в буфер 2 и пришлось повторить на экране кадр из 1. Второй буфер дорисовал, но синхросигнал ещё не пришёл (например, потому что лорисовать оставалось всего 10% и это произошло быстро). Отрисовка пошла в 3 буфер. Второй - в ожидании. Пришёл синхросигнал. Третий буфер не дорисовал ещё 15%. Зато во втором уже есть готовый для вывода кадр! Его и отправляем на вывод, имея в моменте -15% лага на НЕ ожидании завершения фреймтайма.
    Чего тут непонятного-то?...
     
  • 6.130, Alex (??), 13:38, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе же уже по-русски написали, что не всегда ДВА следующих кадра готовы. Может быть готов только 1 из 2. Пример: не успел отрисоваться кадр в буфер 2 и пришлось повторить на экране кадр из 1. Второй буфер дорисовал, но синхросигнал ещё не пришёл (например, потому что лорисовать оставалось всего 10% и это произошло быстро). Отрисовка пошла в 3 буфер. Второй - в ожидании. Пришёл синхросигнал. Третий буфер не дорисовал ещё 15%. Зато во втором уже есть готовый для вывода кадр! Его и отправляем на вывод, имея в моменте -15% лага на НЕ ожидании завершения фреймтайма.
    Чего тут непонятного-то?...
     

  • 1.11, ИмяХ (ok), 11:51, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Тройная буферизация изобретена ещё в 90-х годах. КДЕ только сейчас смогла её осилить. Вот что значит опенсорс.
     
     
  • 2.19, Аноним (4), 11:58, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > КДЕ только сейчас смогла её осилить. Вот что значит опенсорс.

    Уточнение: вейлендный опенсорс после 18 лет разработки.

     
  • 2.56, Аноним (56), 14:25, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Тройная буферизация изобретена ещё в 90-х годах.

    поэтому она сейчас не нужна - есть VRR

     
  • 2.114, Аноним (114), 07:06, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >КДЕ только сейчас смогла её осилить.

    Нет, давно. Ещё раньше гнома.
    Вернее в гноме была, но только в виде патча от canonical.
    Патч также передавался в Debian.
    Тогда все отмечали плавность в Ubuntu, которой не было, например, в Fedora.
    А в апстрим позже приняли.
    В новости же просто про невидию.
    99% проблем - из-за неё, такое впечатление складывается.

     

  • 1.14, Аноним (14), 11:55, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Шел 2026г, линукс на десктопе боролся с рывками отображения рабочего стола.
     
     
  • 2.41, Хрю (?), 13:01, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да, только "кде под вялым" усиленно борется 😀
     
     
  • 3.63, Аноним (-), 14:44, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    потому что под иксами это не побороть, и их выкинули
     
  • 2.66, анон (?), 14:54, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С ними можно бороться бесконечно, потому что проблема принципиально неразрешима.

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

     
  • 2.69, Xo (?), 15:27, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Шел 2026г, линукс на десктопе боролся с рывками отображения рабочего стола.

    Хавай яблоки.

     

  • 1.15, Аноним (56), 11:56, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Непонятен смысл тройной буферизации в KDE - если отрисовка быстрей чем обновляется экран почему нельзя в тот же буфер отрисовать ведь один кадр все равно дропнется, а если там VRR то нафига он на 2d графике десктопов - это же для игр с динамичными сценами.
     
     
  • 2.18, Аноним (16), 11:58, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вялый работает в 3д постоянно. Кажется - 2д вообще не умеет.
     
     
  • 3.21, Аноним (56), 12:00, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вообще к делу не относится - вейланд как угодно работает, даже через старинный фреймбуфер.
     
     
  • 4.28, Аноним (16), 12:15, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А накладные расходы? А задержка?
    И это в случаях когда акселерация и вовсе не нужна.
     
  • 2.22, Аноним (4), 12:03, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > если отрисовка быстрей чем обновляется экран почему нельзя в тот же буфер отрисовать ведь один кадр все равно дропнется

    Именно так. Слишком быстро рисуем - swap не делаем, очищаем back-буфер и снова в него же рисуем. Нарисовали - vsync+swap. Нам-то какая разница - что дроп кадра, что подождать vsync.

     
  • 2.27, Аноним (27), 12:15, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В KDE на 8к 60гц экране гпу ускорение бездействия жрет 60вт даже в простое на пустом рабочем столе, с vrr обрабатывались бы и передавались по идее только измененные кадры. Мобилки давно умеют экономить проц, обновляя экран только когда что-то происходит.
     
     
  • 3.30, Аноним (4), 12:20, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Надо привыкать, что сейчас на современном ПК включил систему - получил сходу 10 ГБ занятой оперативки и 100% нагрузку на GPU+CPU.
     
     
  • 4.37, Ананоним (?), 12:50, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Сегодня на каждый чих по буферу. Вот в былые времена всё рисовалось в один главный буфер и жили.
     
  • 3.31, Аноним (31), 12:22, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, но ведь Linux, очень крутой.
    Эта функция экономии заряда экономит тебе чуть больше 0,1%, но зато дает артефакты отрисовки.
    Что кстати отключается через конфиг Grub.
     
  • 3.44, Аноним (44), 13:31, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    i915.enable_psr=0
    Полностью отключает энергосберегающую технологию Panel Self Refresh.
    По умолчанию PSR усыпляет видеокарту, когда картинка статична. Пробуждение происходит с задержкой в несколько миллисекунд. Отключение (=0) полностью ликвидирует, желейный, Input Lag и микрофризы при начале скроллинга страниц в браузере.

    i915.enable_fbc=0 (или =1)
    Управляет сжатием буфера кадра в видеопамяти, Frame Buffer Compression.
    Значение =1 сжимает данные ради экономии пары милливатт энергии, это часто вызывает мерцание интерфейса и рваный фреймрейт.
    Значение =0 полностью отключает сжатие, обеспечивая максимальную стабильность отрисовки без артефактов.

    Но я не знаю как у вас там на Nvidia H200,
    Или на Nvidia 5060 Gold Edition.
    С серверной Озу, 128Гб, и на nVme за 700$.

     
     
  • 4.60, Аноним (-), 14:41, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    ни одна из этих фич не починит его проблему, а только усугубит

    еще и инпут лага добавит

     
     
  • 5.81, Аноним (84), 16:37, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну у меня то починило.
    Прям 80%, этих глюков убрало.
    Но надо смотреть под конкретное железо.
    И прям не постесняюсь, почти как на Winde с родными драйверами, стало, всмысле без Input Лагов.
    Я даже не знал что может так, не тормозить)
    С оговоркойчто я настроил Labwc, на Wayland, конфиг.
    И Firefox.
    И поставил non-free, драйвера.
    Нр даже без этого сразу 80% тормозов убрало.
     
     
  • 6.128, Аноним (124), 13:24, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    тебе показалось ну то есть не починило не, не надо что почти как в Winde что ст... большой текст свёрнут, показать
     
  • 5.85, Аноним (84), 16:51, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Непонятно что у него за Видюха,
    если Nvidia,
    то,
    nvidia_modeset.disable_vrr_memclk_switch=1

    nvidia-settings, PowerMizer
    вместо Prefer Maximum Performance, на Adaptive.

    Чуть снизить частоту экрана, например с 60 на, 59,94, 50.
    Тайминги изменятся.

    Для вывода 8K 60 Гц  Nvidia используют  DSC (сжатие потока).
    Перейти с DisplayPort 1.4 на HDMI 2.1.

     
     
  • 6.125, Аноним (124), 13:15, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Тайминги изменятся.

    конечно изменятся, на целых 10 отрисовок в секунду меньше будет для режима на 50hz, то есть задержки увеличатся

    > Перейти с DisplayPort 1.4 на HDMI 2.1.

    чтобы ничего не изменилось?

    ps ты уже собрал тот набор для измерения задержек, на который ссылку давал? когда там ждать пруфов на все, что ты выше вывалил?

     
     
  • 7.132, Аноним (132), 15:24, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Критикуешь, предлагай.
    Короч, ты эксперт в данном вопросе.
     
     
  • 8.133, Аноним (-), 17:51, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    предлагаю ты идешь и даешь пруфы на свои утверждения по своим ссылкам там с каки... текст свёрнут, показать
     
  • 3.104, Аноним (104), 23:14, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Мобилки давно умеют экономить проц, обновляя экран только когда что-то происходит.

    Ага, экономят... Только пресс-релизы и прочий маркетинговые... эээ... приукрашивания читаете?

     

  • 1.20, Аноним (20), 11:59, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > ценой увеличения задержки вывода

    А что насчёт уменьшения задержки ввода и заодно снижения растрат пропускной способности видеопамяти? В предыдущих новостях читал, что на встроенных GPU Intel в kwin задействован аппаратный композитинг. Планируется ли подобное на дискретных GPU?

     
     
  • 2.23, Аноним (4), 12:05, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При тройной буферизации лаг между вводом и выводом больше, и расход видеопамяти больше. В общем, всё только отрицательно сказывается.
     
     
  • 3.79, ХозяинАнонимов (?), 16:32, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > При тройной буферизации лаг между вводом и выводом больше

    Неверно.

    > При тройной буферизации расход видеопамяти больше

    Верно.

     
  • 2.29, Аноним (31), 12:20, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >А что насчёт уменьшения задержки ввода и заодно снижения растрат пропускной способности видеопамяти

    Тебе что нужно, уменьшение задержки ввода, нет уж смотри на kWin.
    В lxqt и xfce labwc, нет если что задержки ввода.

     
     
  • 3.61, Аноним (-), 14:42, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > В lxqt и xfce labwc, нет если что задержки ввода.

    пруфы?

     
     
  • 4.80, Аноним (84), 16:33, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поставь попробуй.
    Тебе что видео чтоли записать.
    Wlroots, имеет все фичи, которые Kde, всякие только внедряют.
    А да, с оговоркой, с non-free драйверами.
    А да, то что Input-Lag, в Kde, разрабы называют это гордо, желейный интерфейс.
    Ка бы небыл красив Дезайн, мне важнее отсуствие этих самых Input Lag оф.
    А ну да, возможно ты просто привык к тормозам и считаешь это нормой.
     
     
  • 5.126, Аноним (124), 13:20, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    поставил, ничего не изменилось, кроме удобства использования, оно ухудшилось зап... большой текст свёрнут, показать
     
  • 3.87, Аноним (20), 17:10, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Тебе что нужно

    Аппаратный композитинг. Рендеринг буфера окна не через копирование в фреймбуфер, а прямо на экран, как это обычно делается для вывода видео и курсора мыши.

    > В lxqt и xfce labwc, нет если что задержки ввода.

    Во первых, утверждение неверно в принципе. Задержки ввода есть везде, даже на NES, где буферизации вывода вообще никакой нет.

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

     

  • 1.35, Ананоним (?), 12:49, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тройная буферизация интерфейса? Хаха! Помню на Windows 95 с одним буфером всё работало.
     
  • 1.36, Ананоним (?), 12:49, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нужно бооооольше памяти!
     
     
  • 2.40, Аноним (40), 12:59, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вин11 с ФФ и Каспером ест 5 гигов, а Кеды сколько потребляют?
     
     
  • 3.43, Аноним (44), 13:25, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У нас тут, эксперты говорят что Kde потербляет 800Mb.
    И те кто говорят что 4Гб, просто неправы.
     
  • 3.47, НяшМяш (ok), 13:42, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Те же 5 гигов на 64 гигах ОЗУ при запущенном firefox, thunderbird c 5 ящиками и примерно 50000 писем, яндекс синхронизации через уd-go, telegram и rssguard на примерно 200 каналов.
     
  • 3.48, Аноним (48), 13:43, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
      SYS/WM/DE | top(1)  | htop(1) | conky(1) | freecolor(1)
    ------------+---------+---------+----------+-------------
        FreeBSD |   97 MB |  112 MB |    - -   |  157 MB
        Openbox |  614 MB |  237 MB |  460 MB  |  382 MB
           MATE | 1361 MB |  508 MB |  778 MB  |  788 MB
           XFCE | 1548 MB |  533 MB |  794 MB  |  829 MB
    helloSystem | 1613 MB |  585 MB |  804 MB  |  830 MB
          GNOME | 2622 MB |  625 MB |  990 MB  | 1000 MB
    KDE/Plasma | 2843 MB |  730 MB | 1659 MB  | 1167 MB

    https://vermaden.wordpress.com/2022/07/12/desktop-environments-resource-usage-

     
     
  • 4.76, Аноним (84), 16:26, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь пошевели мышкой в Kde, открой Dolphin, и сравни с Lxqt, Xfce Labwc.
    А еще посмотри потребление Cpu.
    Ато в простое Kde idle 99,8
    Так же как Lxqt, Xfce Labwc.
    Но стоит подаигать мышкой, открыть Dolphin, и идет жор 30-35% Cpu.
    Например Labwc, максимум жор 9%.
    А да, Gnome 18%.
     
     
  • 5.112, Аноним (112), 05:59, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >А теперь пошевели мышкой в Kde, открой Dolphin, и сравни с Lxqt, Xfce Labwc.

    А еще посмотри потребление Cpu.

    Открыл и пошевелил. Максимум 13%, и то изредка.
    Постоянно не грузит.
    Сравнить не могу, ибо нет ни XFCE, ни LXQT.

     
     
  • 6.137, Аноним (137), 20:20, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ты ведь непонимаешь, да.
    Ты как Блоггеры обзорщики.
    Пошевелил на голом Desctop.

    При использовании.
    При открытии браузера.
    При открытии Dolphin.
    При запуске vlc.
    При открытии диалога созранить.
    И все это сразу.

    kWin 30-45% Cpu.
    Labwc 9%.
    Или ты используешь Ос, в однозадачном режиме.

     
  • 3.49, Аноним (1), 13:45, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Плазма около 300мб после загрузки, 450мб на иксах было.
     
     
  • 4.78, Аноним (84), 16:29, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вы там в каком веке. Средневековье еще не прошло.
    На 4Гб, можно только Kde, запустить.
    Может вы еще браузер потребление считаете, Firefox,
    А не, Isolated Web Content).
     
     
  • 5.82, Аноним (1), 16:40, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Если что, pidof firefox показывает все процессы firefox, потом смотришь в smaps и складываешь интересующее значение. Вот тебе реальное потребление. Что-то в районе 1 гигабайта, плюс примерно половина в свопе лежит и никак не используется.
     
     
  • 6.90, Аноним (90), 19:47, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    top -p $(pgrep -f firefox | tr '\n' ',' | sed 's/,$//')
     
     
  • 7.92, Аноним (1), 20:03, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Топ врёт. И пс тоже. Гномовский монитор ресурсов тоже врёт точно знаю. Htop, по-моему, не врал, glances тоже.
     
     
  • 8.101, Аноним (101), 22:14, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Они все функциклируют по одному и тому же принципу, просто разная оболочка Незн... текст свёрнут, показать
     
     
  • 9.102, Аноним (1), 22:49, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Я смотрел RSS и PSS, а также SHARED Там много стратегий считать сколько памяти ... текст свёрнут, показать
     
     
  • 10.107, Аноним (107), 00:39, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Молодец ... текст свёрнут, показать
     
  • 4.138, Аноним (137), 20:22, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >300мб после загрузки, 450мб на иксах было

    Вот и запускай там свою Kde, которая 300мб, 450мб на иксах, на 512Мб Озу.
    Зачем ты на сайты пишешь.

    Это у тебя так.
    А у всех по 2-5Гб.

     
     
  • 5.139, Аноним (1), 20:56, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да нормально у меня озу, просто мне нравится когда не тратится память впустую. Ну там на левые библиотеки которые никогда не используются и так далее, поэтому программы на разных тулкитах лучше не держать, когда у тебя в памяти минимум 5 вебкитов это не дело. Чушь какая, кеды и 2-5гб? У тебя там флатпаки или статическая линковка?
     
  • 3.50, Аноним (1), 13:47, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не, я имею в виду вместе с ядром. Ядро отнимает около 100мб под себя с видеодрайвером, без него ядро около 30мб.
     

  • 1.45, Аноним (45), 13:31, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А когда будет четверная буферизация?
     
     
  • 2.53, выхухо (?), 13:59, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    сразу после появления "отражений бликов луны на гладкой жопе монстра". или как там в оригинале.
     

  • 1.51, Аноним (51), 13:49, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сколько же здесь умников собралось, которые не понимают смысл тройной буферизаци... большой текст свёрнут, показать
     
     
  • 2.54, выхухо (?), 14:01, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    крч, за що боролись, то и получили. втройне.
     
  • 2.55, Аноним (1), 14:09, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это всегда так было, если рендерить с запасом будет быстрее и фреймрейт стабильнее, увеличивает лаг конечно, но статтеринг выбесит быстрее лага. Но допустим 5 фреймов из 30 не заметить сложно, из 60 тоже можно заметить. 2 фрейма из прошлого? Не, не увидишь. 1 просто может не успеть всегда. Но сейчас на nvidia уже не только фреймы из прошлого показывает, но и из будущего, можно 5 фреймов рендерить когда их ещё нет в принципе и без задержки соответсвенно.
     
  • 2.62, Аноним (62), 14:43, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Во-первых, автор новости написал, что тройную буферизацию включили. Так внезапно, включили ее возможность, а не ее саму.

    Включили по умолчанию, смотрите коммит https://invent.kde.org/plasma/kwin/-/merge_requests/9472

    "Since the bug is fixed, and there don't seem to be any other issues anymore, we can enable it by default".

    кусок из diff-а:

    + static const auto s_disableTripleBuffering = environmentVariableBoolValue("KWIN_DRM_DISABLE_TRIPLE_BUFFERING");

    + if (m_gpu->atomicModeSetting() && !s_disableTripleBuffering.value_or(false)) {

    Т.е. если не выставлена переменная окружения "KWIN_DRM_DISABLE_TRIPLE_BUFFERING", тройная буферизация будет включена.

     
     
  • 3.93, Аноним (93), 21:22, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    1 в сообщение коммита написано allow, ну уж должно как-то на мысль наводить, то... большой текст свёрнут, показать
     
  • 2.64, Аноним (56), 14:54, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Во-вторых, тройная буферизация нужна не для отрисовки десктопа.

    а для чего она в kwin если не для отрисовки десктопа? Тебе нужно понять что такое синхронизация с vsync - кадр рендерится либо в один буфер во время vblank или рендерится в теневой буфер и видимый переключается во время vblank, сколько теневых буферов 1 или 2 особой разницы нет если графика не успевает отрисовываться просто отображается старый буфер, если тебе надо можно просто увеличить частоту кадровой развертки тогда меньше будешь ожидать vblank

     
     
  • 3.95, Аноним (93), 21:26, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно, что для приложений по большей части. Десктоп большую часть времени статичен, и тройная буферизация именно для него включается редко.
     
  • 2.65, Аноним (62), 14:54, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Смысл тройной буферизации объясняется вот здесь: https://zamundaaa.github.io/wayland/2024/06/25/fixing-kwin-perf-on-old-hardwar

    "So, with these old Intel processors, KWin should now detect that rendering takes long and render times are not very stable..."

    Там речь про хак с адаптивным отключением тройной буферизации для старых GPU Intel, а здесь речь про включение для GPU NVIDIA.


     
     
  • 3.94, Аноним (93), 21:24, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Хак с адаптивным ВКЛЮЧЕНИЕМ. Раньше он был запрещен для NVIDIA, теперь разрешили.
     

  • 1.72, Аноним (72), 15:46, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Я не знаю что такое буферизация, но я помню, что умел компиз на Gnome-2, с тремя гектарами ОЗУ на дешманском селероне с 1,8 GhZ и встройкой, а сейчас только одно "современное" DE потребляет как вся Десяточка, да ещё и наглухо уходит в подкачку с 8 гектарами ОЗУ.
     
     
  • 2.73, Zenitur (ok), 16:18, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На данный момент у меня Debian на i965, а в качестве DE я использую MATE. Проект Compiz Reloaded продолжил развитие Compiz 0.8 после того, как 0.9 перешёл на C++. Также в Compiz Reloaded добавлена поддержка MATE (причём как версии GTK2, на которой была Debian 8, так и GTK3).

    Работает просто отлично. Жаль, что официальный репозиторий на tuxfamily перестал открываться с начала 2026 года (есть в веб-архиве), но пакеты Compiz Reloaded уже есть в основном репозитории Debian.

    Частота обновления экрана у меня определяется автоматически (на NVIDIA с этим были проблемы, тогда как на i965 проблем нет). Даже если подключить по HDMI телевизор (работающий под другой частотой), не надо ни Компиз перезапускать, ни приложение.

    Заметил только, что тиринг появляется только в том случае, когда я восстанавливаю браузер после закрытия, и в одной вкладке у меня YouTube-видео с ускорением VA-API, а в другой - прогружается длиннющий диалог с Google AI. Решилось патчем:

    https://www.linux.org.ru/forum/desktop/5278914

    Теперь смена кадров стала идеальная всегда, даже в той специфической ситуации выше. Я включил Compiz и забыл про тиринг, его теперь нет по-определению. Без TearFree, без FreeSync, без тройной буферизации, без FullCompositionPipeline... Я просто навсегда избавился от тиринга. Забыл, что он в принципе существует.

    Вот последний патч: https://www.linux.org.ru/forum/desktop/9490345
    Вот прямая ссылка: https://raw.githubusercontent.com/istitov/stuff/3ee6e9a569f137d1212e056fd0569c

    Как ни странно, он без проблем накладывается даже на последний Compiz Reloaded 0.8.18.

     
     
  • 3.97, Аноним (93), 21:42, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну очевидно, что композитинг позволяет минимизировать тиринг. Потому что композитный менеджер сначала формирует кадр полностью, а потом отправляет его на отрисовку.

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

     
     
  • 4.115, Zenitur (ok), 07:10, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я знаю, Compiz это "совсем композитинг". Куб рабочего стола, желобразные окна - вот это вот всё.

    Накладные расходы конечно есть - в Компизе включен Sync to VBlank.

     
  • 2.75, Аноним (84), 16:22, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я помню что умел Win7, с 1Гб озу, прозрачности, с Aero, и все это отрисовка Gpu.
     

  • 1.77, Аноним (77), 16:27, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я думал вяленд нужен был чтобы избавиться от лишней буферизации...
     
     
  • 2.86, Аноним (20), 17:00, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > вяленд нужен был чтобы избавиться от лишней буферизации...

    Только лишь по сравнению с композитным режимом Xorg. По сравнению с классическим режимом он только добавляет целую кучу буферов вывода, по два на каждое окно, теперь — по три, с соответствующим увеличением задердек.

     
  • 2.99, Аноним (101), 22:13, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Kde, это лучшее).
     

  • 1.89, Аноним (89), 19:00, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вертикальная развёртка.
    Звучит как нечто из прошлого века.
     
     
  • 2.96, Аноним (93), 21:35, 27/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Оно до сих пор есть. Неожиданно, правда? Вот на твоем супер-пупер LCD-мониторе из этого века input lag в нижней части экрана больше, чем в верхней. Добро пожаловать в реальность из мира розовых пони.
     
     
  • 3.108, Аноним (4), 00:53, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вопрос не в том, есть ли она сейчас, а в том, что KDE только сейчас догадалась про это.
     
     
  • 4.117, Аноним (93), 10:03, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В KDE про это догадались 5 лет назад: https://invent.kde.org/plasma/kwin/-/commit/b8a70e62d53591130a284adea9a56eb20e
    "The RenderLoop tries to minimize the latency by delaying compositing as
    close as possible to the next vblank event."
     
     
  • 5.123, Аноним (4), 12:48, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > В KDE про это догадались 5 лет назад

    Ух! Прям в 21-ом году 21-го века? Вот это скорость разработки!

     
  • 3.111, Zenitur (ok), 05:55, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А не наоборот? Монитор ждёт кадр, а в это время фреймбуфер заполняется строчка за строчкой. Последнюю строку отрисовали - сразу на монитор. Значит инпут лаг последней строчки - маленький. А первой - большой.
     
     
  • 4.118, Аноним (20), 10:08, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Последнюю строку отрисовали - сразу на монитор.

    Изображение в монитор не сразу целиком попадает, а последовательно строчка за строчкой сверху вниз. Частота передачи пикселей обычно выбирается так, что последняя строчка уходит непосредственно перед началом отрисовки следующего кадра. Соответственно, монитор не ждёт, а рисует непрерывно. Ждёт только композитор, дабы не допустить отрисовки кадров с разрывом посередине.

     
     
  • 5.121, Zenitur (ok), 11:38, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вон оно что. Ну, теперь буду знать.
     
  • 4.119, Аноним (93), 10:10, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, монитор не ждет кадр. Он читает данные из фреймбуфера построчно и отображает.

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

    Вот тут можно почитать: https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html

     
  • 2.122, Аноним (122), 12:22, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Телевизор, Заря.
    Ламповый.
     

  • 1.105, Аноним (104), 23:17, 27/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Тройная? Дожили, окно с тенью без 3D не нарисовать...
     
     
  • 2.120, Аноним (70), 11:17, 28/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Видеокарты nvidia и amd, лишенные выделенных аппаратных блоков 2d графики вышли в ~2008 году. С тех пор 2d эмулируется на шейдерах. Даже если у тебя дравер не загружен, прошивка карточки сама содержит необходимый шейдер, который эмулирует работу VGA.
     

  • 1.110, Брату_перезвони_зайбал (?), 04:49, 28/06/2026 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +1 +/
     
  • 1.131, Аноним (4), 14:44, 28/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Шла вторая четверть 21 века: KDE учится переключать буфера.
     
  • 1.135, Аноним (135), 18:35, 28/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот поэтому я использую Gnome.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру