Bris: Varför kommer det inte som standard i KDE 5?

Som vi redan vet släpptes KDE Next (eller KDE 5 som du föredrar) som stabilt för några dagar sedan och bland de nya funktionerna som det ger är en av de mest omtalade det nya konstverket som heter Breeze.

De som redan har provat den här nya versionen eller har sett videon kanske har märkt att i fallet med fönsterdekoratorn är den som kommer som standard syre och inte bris. Också Martin Gräßlin förklarar oss på sin blogg vad är anledningen till detta beslut.

Eftersom artikeln är på engelska kommer jag att försöka ge dig den grundläggande idén om detta.

Varför kommer inte Breeze som standard?

Jag börjar med en förklaring av hur fönsterdekorationer fungerar i KWin 4. KWin är den så kallade re-parenting till fönsterhanterare. Detta innebär att fönstret som hanteras av X11 placeras i ett annat X11-fönster som ger fönsterramen. På KWin använder vi QWidget för fönsterramen. Därför är vi också begränsade till vad QWidget ger oss ... Vår lösning är att fånga upp alla dekorationsmålningshändelser i QWidget och undertrycka den, utlösa en ommålning av kompositören och i återgivningssteget garantera dekorationen av en tillfällig bild som då kopieras till en struktur.

Breeze temafönster dekoration är baserad på Aurorae tema motor. Eftersom jag är huvudförfattare till Aurorae kan jag göra det i det här blogginlägget utan att känna mig dålig om det 🙂 Aurorae var utformat för att vara väldigt enkelt att skapa en dekoration och använda de nya genomskinlighetens funktioner. Att vara en lösning som kan användas som standarddekoration, men det var aldrig deras mål. Tanken var att tillåta användare som vill anpassa den här funktionen, medan de flesta användare kan använda inhemska teman som är snabbare. Aurorae var aldrig snabb och hon kommer inte att vara snabb.

Nu i KWin 5 är användningen av QML det största problemet som gör Aurorae svårt att använda. QtQuick använder Scenegraph och använder QWindows istället för QWidget. Det är en bummel för vårt QWidget-baserade API. Vi justerade den interna användningen för att stödja QWindows-baserade dekorationer, men det var ganska svårt eftersom det finns skillnader i fönstrenas beteende. Eftersom det inte längre är baserat på QWidget är vår färghändelse fångad och vi behövde en ny lösning för det. Och den här lösningen är ännu fulare än den tidigare eftersom QtQuick för närvarande arbetar genom OpenGL. På grund av begränsningar i OpenGL Qt-applikationen (kan adresseras i Qt 5.4) som vi inte kan dela med OpenGL-sammanhanget som används av QtQuick ... Detta är inte bara en enorm kostnad när du kopierar innehållet från GPU till RAM och tillbaka igen till GPU förlorar du också mycket minne. Vid ett maximerat fönster är det inte bara titelraden utan hela fönstret. Och det finns den overhead för varje fönster.

Det ensamma kan göra Aurorae helt oanvändbar. Jag använder för närvarande Breeze-temat och KWin behöver mer än 200 MB RAM - inte riktigt acceptabelt. Men situationen är ännu värre. Med QWindows kan vi inte veta vilka områden som har uppdaterats. Så när till exempel en knapp uppdateras måste vi måla om hela fönstret, inklusive den fullständiga kopian av dekorationsinnehållet. Särskilt i animationssituationer är det ett stort problem.

Så vad är vägen framåt? Jag började implementera en ny dekoration för API genom att ta bort begränsningen av den välbefinnande dekorationen från QWidget och samtidigt började jag implementera Breeze-dekorationen med detta nya API. Hoppas vi kan introducera detta i KWin 5.1.

Och så är det, herrar. Jag hoppas att du förstår mer eller mindre vad problemet är. Jag kommer att fråga Martin om det inte är mer praktiskt och snabbare att göra det inhemska Breeze-temat som Oxygen, även om jag för närvarande inte är orolig, Oxygen även om det inte är den sötaste saken i världen, det har många alternativ ..