Бриз: Чому він не приходить за замовчуванням у KDE 5?

Як ми вже знаємо, KDE Next (або KDE 5, як вам подобається) вийшов стабільним кілька днів тому, і серед нових функцій, які він пропонує, однією з найбільш обговорюваних є нова робота під назвою Breeze.

Ті, хто вже випробував цю нову версію або бачили відео, можливо, помітили, що у випадку з декоратором вікон, за замовчуванням використовується той, що є киснем, а не бризом. Так само Мартін Греслін пояснює нам у своєму блозі в чому причина такого рішення.

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

Чому Breeze не приходить за замовчуванням?

Я починаю з пояснення того, як працюють декорації вікон у KWin 4. KWin - це так зване повторне виховання менеджерів вікон. Це означає, що кероване вікном X11 поміщається в інше вікно X11, яке забезпечує віконну раму. У KWin ми використовуємо QWidget для віконної рами. Тому ми також обмежуємося тим, що нам надає QWidget ... Наше рішення полягає в тому, щоб перехопити всі події розпису прикрас у QWidget і придушити це, викликати перефарбовування композитора та на етапі візуалізації гарантувати оздоблення тимчасового зображення, яке потім копіюється в текстуру.

Оздоблення вікон теми Breeze засноване на тематичному механізмі Aurorae. Оскільки я є головним автором полярних сяйв, я можу зачепити його в цьому дописі в блозі, не відчуваючи при цьому поганого відчуття. 🙂 Полярне сяйво було розроблено для того, щоб дуже легко створити прикрасу та використовувати нові функції напівпрозорості. Будучи рішенням, яке можна використовувати як декорацію за замовчуванням, але це ніколи не було їх метою. Ідея полягала в тому, щоб дозволити користувачам, які хочуть налаштувати цю функцію, тоді як більшість користувачів можуть використовувати рідні теми, які швидші. Полярні сяйва ніколи не були швидкими і вона не буде швидкими.

Зараз у KWin 5 використання QML є основною проблемою, яка ускладнює використання полярних сяйв. QtQuick використовує Scenegraph і використовує QWindows замість QWidget. Це неповноцінно для нашого API на основі QWidget. Ми скоригували внутрішнє використання для підтримки декорацій на основі QWindows, але це була досить складна дорога, оскільки існують відмінності у поведінці вікон. Оскільки він більше не заснований на QWidget, наше захоплення подій фарби порушено, і нам потрібно було нове рішення для нього. І це рішення навіть потворніше попереднього, оскільки QtQuick наразі працює через OpenGL. Через обмеження в програмі OpenGL Qt (може бути розглянуто в Qt 5.4), яку ми не можемо поділитися з контекстом OpenGL, що використовується QtQuick ... Це не тільки величезні накладні витрати при копіюванні вмісту з графічного процесора в оперативну пам'ять і назад до GPU, ви також втрачаєте багато пам'яті. У випадку розгорнутого вікна це не тільки рядок заголовка, але і все вікно. І це накладні витрати на кожне вікно.

Це одне може зробити Аврори абсолютно непридатними для використання. В даний час я використовую тему Breeze, і KWin потребує більше 200 Мб оперативної пам'яті - не дуже прийнятно. Але ситуація ще гірша. За допомогою QWindows ми не можемо знати, які області оновлено. Отже, коли, наприклад, кнопка оновлюється, ми повинні перефарбувати все вікно, включаючи повну копію вмісту прикраси. Це особливо в анімаційних ситуаціях є великою проблемою.

Отже, який шлях вперед? Я почав впроваджувати нову обробку для API, скасувавши обмеження оздоблення на основі добробуту з QWidget, і одночасно я почав впроваджувати оздоблення Breeze за допомогою цього нового API. Сподіваємось, ми можемо представити це в KWin 5.1.

І все так, панове. Сподіваюся, ви більш-менш розумієте, в чому проблема. Я збираюся запитати у Мартіна, чи не практичніше і швидше зробити рідну тему Бризу, як Oxygen, хоча на даний момент я не хвилююся, Oxygen, хоча це не наймиліша річ у світі, у неї є багато варіантів ..