Breeze: Waarom komt het niet standaard in KDE 5?

Zoals we al weten, is KDE Next (of KDE 5 zoals je wilt) een paar dagen geleden uitgebracht als stabiel en onder de nieuwe functies die het met zich meebrengt, is een van de meest besproken het nieuwe Artwork genaamd Breeze.

Degenen die deze nieuwe versie al hebben geprobeerd of de video hebben gezien, hebben misschien gemerkt dat in het geval van de raamdecorateur standaard Oxygen is en niet Breeze. Nou dan Martin Gräßlin legt ons uit op zijn blog Wat is de reden van deze beslissing?

Aangezien het artikel in het Engels is, zal ik proberen u het basisidee hiervan te geven.

Waarom komt Breeze niet standaard?

Ik begin met uit te leggen hoe raamdecoratie werkt in KWin 4. KWin is het zogenaamde re-ouderschap van raambeheerders. Dit betekent dat het door X11 beheerde raam in een ander X11-raam wordt geplaatst dat het raamkozijn levert. In KWin gebruiken we QWidget voor het raamkozijn. We zijn dus ook beperkt tot wat QWidget ons biedt... Onze oplossing is om alle decoratie-verfgebeurtenissen in QWidget te onderscheppen en te onderdrukken, een herschildering van de compositor te activeren en in de weergavestap decoraties te garanderen naar een tijdelijke afbeelding die vervolgens wordt gekopieerd naar een textuur.

De Breeze thema raamdecoratie is gebaseerd op de Aurorae thema engine. Aangezien ik de hoofdauteur ben van Aurorae, kan ik het op deze blogpost plaatsen zonder me er slecht over te voelen 🙂 Aurorae is ontworpen om het heel gemakkelijk te maken om een ​​decoratie te maken en gebruik te maken van de nieuwe doorschijnendheidsfuncties. Een oplossing zijn die standaard als decoratie zou kunnen worden gebruikt, maar het was nooit het doel. Het idee was om gebruikers die deze functie willen aanpassen toe te staan, terwijl de meeste gebruikers de snellere native thema's kunnen gebruiken. Aurorae was nooit snel en zal ook niet snel zijn.

Nu in KWin 5 is het gebruik van QML het grootste probleem dat het moeilijk maakt om Aurorae te gebruiken. QtQuick gebruikt de Scenegraph en gebruikt QWindows in plaats van QWidget. Dat is jammer voor onze op QWidget gebaseerde API. We hebben het interne gebruik aangepast om op QWindows gebaseerde versieringen te ondersteunen, maar dat was nogal een lastige weg, omdat er verschillen zijn in het gedrag van vensters. Omdat het niet langer gebaseerd is op QWidget, breekt onze paint event trapping en hadden we een nieuwe oplossing nodig. En deze oplossing is nog lelijker dan de vorige omdat QtQuick momenteel via OpenGL werkt. Vanwege beperkingen in de OpenGL Qt-implementatie (mogelijk behandeld in Qt 5.4) die we niet kunnen delen met de OpenGL-context die wordt gebruikt door QtQuick... Dit is niet alleen een enorme overhead bij het kopiëren van inhoud van de GPU naar RAM en terug naar de GPU, het verspilt ook veel geheugen. In het geval van een gemaximaliseerd venster is het niet alleen de titelbalk, maar het hele venster. En er is die overhead voor elk raam.

Dat alleen al kan Aurorae totaal onbruikbaar maken. Ik gebruik momenteel het Breeze-thema en KWin heeft meer dan 200 MB RAM nodig - niet echt acceptabel. Maar de situatie is nog erger. Met QWindows komen we niet te weten welke gebieden zijn bijgewerkt. Dus wanneer bijvoorbeeld een knop wordt bijgewerkt, moeten we het hele venster opnieuw schilderen, inclusief de volledige kopie van de decoratie-inhoud. Dat is vooral in animatiesituaties een groot probleem.

Dus wat is de weg te gaan? Ik ben begonnen met het implementeren van een nieuwe decoratie voor de API, waardoor QWidget's beperking van decoratie op basis van welzijn werd opgeheven en tegelijkertijd begon ik Breeze-decoratie te implementeren met deze nieuwe API. Ik hoop dat we dit kunnen introduceren in KWin 5.1.

En zo is het heren. Ik hoop dat je min of meer begrijpt wat het probleem is. Ik ga Martin vragen of het niet praktischer en sneller is om het Breeze-thema native te maken zoals Oxygen, hoewel ik me op dit moment geen zorgen maak, Oxygen hoewel het niet het mooiste ter wereld is, het heeft veel opties..