Brise: Hvorfor kommer det ikke som standard i KDE 5?

Som vi allerede ved, blev KDE Next (eller KDE 5 som du foretrækker) frigivet som stabil for et par dage siden, og blandt de nye funktioner, det bringer, er et af de mest omtalte det nye illustrationer kaldet Breeze.

De, der allerede har prøvet denne nye version eller har set videoen, har muligvis bemærket, at i tilfælde af vinduesdekoratøren er den der kommer som standard Oxygen og ikke Breeze. Såvel Martin Gräßlin forklarer os på hans blog hvad er årsagen til denne beslutning?

Da artiklen er på engelsk, vil jeg forsøge at bringe dig den grundlæggende idé om dette.

Hvorfor kommer Breeze ikke som standard?

Jeg starter med forklaringen på, hvordan vinduesdekorationer fungerer i KWin 4. KWin er den såkaldte re-parenting af vinduesadministratorer. Dette betyder, at det X11-styrede vindue sættes i et andet X11-vindue, der giver vinduesrammen. Hos KWin bruger vi QWidget til vinduesrammen. Derfor er vi også begrænset til det, som QWidget giver os ... Vores løsning er at opfange alle dekorationsmaleribegivenheder i QWidget og undertrykke det, udløse en gentegning af komponisten og i gengivelsestrinet garantere udsmykningen af ​​et midlertidigt billede, der derefter kopieres ind i en struktur.

Breeze-temaets vinduesdekoration er baseret på Aurorae-tema-motoren. Da jeg er hovedforfatter af Aurorae, kan jeg slå det op på dette blogindlæg uden at føle mig dårligt om det 🙂 Aurorae blev designet til at være meget let at skabe en dekoration og gøre brug af de nye gennemsigtighedsfunktioner. At være en løsning, der kunne bruges som standarddekoration, men det var aldrig deres mål. Ideen var at tillade brugere, der ønsker tilpasning af denne funktion, mens de fleste brugere kan bruge native temaer, der er hurtigere. Aurorae var aldrig hurtig, og hun vil ikke være hurtig.

Nu i KWin 5 er brugen af ​​QML det største problem, der gør Aurorae vanskelig at bruge. QtQuick bruger Scenegraph og bruger QWindows i stedet for QWidget. Det er en bummer for vores QWidget-baserede API. Vi justerede den interne brug til at understøtte QWindows-baserede dekorationer, men det var en ganske vanskelig vej, da der er forskelle i vinduesadfærd. Da det ikke længere er baseret på QWidget, er vores fangst af malingsbegivenheder brudt, og vi havde brug for en ny løsning til det. Og denne løsning er endnu grimmere end den forrige, fordi QtQuick i øjeblikket arbejder gennem OpenGL. På grund af begrænsninger i OpenGL Qt-applikationen (kunne adresseres i Qt 5.4), som vi ikke kan dele med OpenGL-konteksten, der bruges af QtQuick ... Dette er ikke kun et stort overhead, når vi kopierer indholdet fra GPU'en til RAM og tilbage igen til GPU'en, mister du også meget hukommelse. I tilfælde af et maksimeret vindue er det ikke kun titellinjen, men hele vinduet. Og der er den overhead for hvert vindue.

Det alene kan gøre Aurorae helt ubrugelig. Jeg bruger i øjeblikket Breeze-temaet, og KWin har brug for mere end 200 MB RAM - ikke rigtig acceptabelt. Men situationen er endnu værre. Med QWindows kan vi ikke vide, hvilke områder der blev opdateret. Så når for eksempel en knap opdateres, skal vi male hele vinduet igen, inklusive den komplette kopi af dekorationsindholdet. Det er især et stort problem i animationssituationer.

Så hvad er vejen frem? Jeg begyndte at implementere en ny dekoration til API'en ved at fjerne begrænsningen af ​​den wellness-baserede dekoration fra QWidget, og på samme tid begyndte jeg at implementere Breeze-dekorationen med denne nye API. Håber vi kan introducere dette i KWin 5.1.

Og sådan er det, mine herrer. Jeg håber, du forstår mere eller mindre, hvad problemet er. Jeg vil spørge Martin, om det ikke er mere praktisk og hurtigere at lave det oprindelige Breeze-tema som ilt, selvom jeg i øjeblikket ikke er bekymret, ilt selvom det ikke er den sødeste ting i verden, det har en masse muligheder