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

Som vi allerede vet, ble KDE Next (eller KDE 5 som du foretrekker) utgitt som stabil for noen dager siden, og blant de nye funksjonene den bringer, er en av de mest omtalte det nye kunstverket som heter Breeze.

De som allerede har prøvd denne nye versjonen eller har sett videoen, har kanskje lagt merke til at i tilfelle vindusdekoratøren er Oxygen og ikke Breeze den som kommer som standard. Også Martin Gräßlin forklarer oss på bloggen sin hva er årsaken til denne avgjørelsen.

Siden artikkelen er på engelsk, vil jeg prøve å gi deg den grunnleggende ideen om dette.

Hvorfor kommer ikke Breeze som standard?

Jeg begynner med forklaringen på hvordan vindusdekorasjoner fungerer i KWin 4. KWin er den såkalte re-parenting av vindusledere. Dette betyr at vinduet som administreres av X11 settes inn i et annet X11-vindu som gir vindusrammen. På KWin bruker vi QWidget til vindusrammen. Derfor er vi også begrenset til hva QWidget gir oss ... Vår løsning er å fange opp alle dekorasjonsmaleringshendelser i QWidget og undertrykke det, utløse en maling av komponisten på nytt og i gjengivelsesteget garantere dekorasjonen av et midlertidig bilde som deretter kopieres inn i en tekstur.

Vinduet på Breeze-temaet er basert på Aurorae-tema-motoren. Siden jeg er hovedforfatter av Aurorae, kan jeg slå den opp på dette blogginnlegget uten å føle meg dårlig om det. Aurorae ble designet for å være veldig enkelt å lage en dekorasjon og bruke de nye gjennomsiktighetsfunksjonene. Å være en løsning som kan brukes som standard dekorasjon, men det var aldri deres mål. Ideen var å tillate brukere som ønsker å tilpasse denne funksjonen, mens de fleste brukere kan bruke innfødte temaer som er raskere. Aurorae var aldri rask, og hun vil ikke være rask.

Nå i KWin 5 er bruk av QML hovedproblemet som gjør Aurorae vanskelig å bruke. QtQuick bruker Scenegraph og bruker QWindows i stedet for QWidget. Det er en bummer for QWidget-basert API. Vi justerte den interne bruken for å støtte QWindows-baserte dekorasjoner, men det var ganske vanskelig, siden det er forskjeller i oppførselen til vinduene. Siden det ikke lenger er basert på QWidget, er fangst av malingshendelser ødelagt, og vi trengte en ny løsning for det. Og denne løsningen er enda styggere enn den forrige fordi QtQuick for tiden jobber gjennom OpenGL. På grunn av begrensninger i OpenGL Qt-applikasjonen (kan adresseres i Qt 5.4) som vi ikke kan dele med OpenGL-konteksten som brukes av QtQuick ... Dette er ikke bare en enorm overhead når du kopierer innholdet fra GPU til RAM og tilbake igjen til GPUen, kaster du også bort mye minne. I tilfelle et maksimert vindu er det ikke bare tittellinjen, men hele vinduet. Og det er den overhead for hvert vindu.

Det alene kan gjøre Aurorae totalt ubrukelig. Jeg bruker for øyeblikket Breeze-temaet, og KWin trenger mer enn 200 MB RAM - egentlig ikke akseptabelt. Men situasjonen er enda verre. Med QWindows kan vi ikke vite hvilke områder som ble oppdatert. Så når for eksempel en knapp oppdateres, må vi male hele vinduet på nytt, inkludert den komplette kopien av dekorasjonsinnholdet. Særlig i animasjonssituasjoner er det et stort problem.

Så hva er veien videre? Jeg begynte å implementere en ny dekorasjon for API ved å fjerne begrensningen på den velværebaserte dekorasjonen av QWidget, og samtidig begynte jeg å implementere Breeze-dekorasjonen med denne nye APIen. Håper vi kan introdusere dette i KWin 5.1.

Og slik er det, mine herrer. Jeg håper du forstår mer eller mindre hva problemet er. Jeg kommer til å spørre Martin om det ikke er mer praktisk og raskere å lage det opprinnelige Breeze-temaet som Oxygen, selv om jeg for øyeblikket ikke er bekymret, Oxygen selv om det ikke er den søteste tingen i verden, den har mye alternativer ..