Breeze: Dlaczego w KDE 5 nie jest to opcja domyślna?

Jak już wiemy, KDE Next (lub KDE 5, jak wolisz) zostało wydane jako stabilne kilka dni temu, a wśród nowych funkcji, które przynosi, jedną z najczęściej omawianych jest nowa grafika o nazwie Breeze.

Ci, którzy już wypróbowali tę nową wersję lub widzieli wideo, mogli zauważyć, że w przypadku dekoratora okien domyślnie pojawia się Oxygen, a nie Breeze. No więc Martin Gräßlin wyjaśnia nam na swoim blogu Jaki jest powód tej decyzji?

Ponieważ artykuł jest w języku angielskim, postaram się przedstawić podstawową ideę tego.

Dlaczego Breeze nie pojawia się domyślnie?

Zacznę od wyjaśnienia, jak działają dekoracje okien w KWin 4. KWin to tak zwane ponowne rodzicielstwo menedżerów okien. Oznacza to, że okno zarządzane przez X11 jest umieszczane w innym oknie X11, które zapewnia ramkę okna. W KWin używamy QWidget dla ramki okna. Dlatego jesteśmy również ograniczeni do tego, co zapewnia nam QWidget... Naszym rozwiązaniem jest przechwycenie wszystkich zdarzeń malowania dekoracji w QWidget i stłumienie ich, wywołanie przemalowania kompozytora i na etapie renderowania zagwarantowanie dekoracji tymczasowemu obrazowi, który następnie jest kopiowany do tekstury.

Dekoracja okna motywu Breeze jest oparta na silniku motywu Aurorae. Ponieważ jestem głównym autorem Aurorae, mogę umieścić go w tym poście na blogu, nie czując się z tego powodu źle 🙂 Aurorae została zaprojektowana tak, aby bardzo ułatwić tworzenie dekoracji i korzystanie z nowych funkcji przezroczystości. Bycie rozwiązaniem, które domyślnie mogłoby służyć jako dekoracja, ale nigdy nie było to jego celem. Pomysł polegał na umożliwieniu użytkownikom, którzy chcą dostosować tę funkcję, podczas gdy większość użytkowników może korzystać z szybszych motywów natywnych. Aurorae nigdy nie była szybka i szybko nie będzie.

Obecnie w KWin 5 używanie QML jest głównym problemem utrudniającym korzystanie z Aurorae. QtQuick używa Scenegraph i używa QWindows zamiast QWidget. To kłopot dla naszego API opartego na QWidget. Dostosowaliśmy użycie wewnętrzne do obsługi dekoracji opartych na QWindows, ale była to dość trudna droga, ponieważ istnieją różnice w zachowaniu okien. Ponieważ nie jest już oparty na QWidget, nasze zalewkowanie zdarzeń malowania się psuje i potrzebowaliśmy nowej poprawki. A to rozwiązanie jest jeszcze brzydsze niż poprzednie, ponieważ QtQuick działa obecnie przez OpenGL. Ze względu na ograniczenia w implementacji OpenGL Qt (które mogą zostać rozwiązane w Qt 5.4) nie możemy udostępniać kontekstu OpenGL używanego przez QtQuick... To nie tylko ogromny narzut podczas kopiowania zawartości z GPU do RAM iz powrotem do GPU, tracisz też dużo pamięci. W przypadku zmaksymalizowanego okna to nie tylko pasek tytułu, ale całe okno. I jest to narzut dla każdego okna.

Samo to może sprawić, że Aurorae będzie całkowicie bezużyteczna. Obecnie używam motywu Breeze, a KWin potrzebuje więcej niż 200 MB pamięci RAM - nie do przyjęcia. Ale sytuacja jest jeszcze gorsza. W QWindows nie wiemy, które obszary zostały zaktualizowane. Kiedy więc np. aktualizowany jest przycisk, musimy przemalować całe okno, łącznie z pełną kopią zawartości dekoracji. To, zwłaszcza w sytuacjach związanych z animacją, stanowi duży problem.

Więc jaka jest droga? Zacząłem wdrażać nową dekorację dla API, usuwając ograniczenia QWidget dotyczące dekoracji w oparciu o dobre samopoczucie i jednocześnie zacząłem wdrażać dekorację Breeze z tym nowym API. Mam nadzieję, że uda nam się to wprowadzić w KWin 5.1.

I tak to jest panowie. Mam nadzieję, że mniej więcej rozumiesz, na czym polega problem. Zamierzam zapytać Martina, czy nie jest to bardziej praktyczne i szybsze, aby motyw Breeze był natywny jak Oxygen, chociaż w tej chwili się nie martwię, Tlen, chociaż nie jest najpiękniejszą rzeczą na świecie, ma wiele opcje ..