Breeze: Miksi se ei tule oletusarvoisesti KDE 5: ssä?

Kuten jo tiedämme, KDE Next (tai mieluummin KDE 5) julkaistiin muutama päivä sitten vakaana ja sen tuomien uusien ominaisuuksien joukossa yksi eniten puhuttu on uusi Breeze-niminen taideteos.

Ne, jotka ovat jo kokeilleet tätä uutta versiota tai ovat nähneet videon, ovat saattaneet huomata, että ikkuna-koristelijan tapauksessa oletusarvoisesti tulee happi eikä Breeze. Yhtä hyvin Martin Gräßlin selittää meille hänen blogissaan mikä on tämän päätöksen syy.

Koska artikkeli on englanniksi, yritän tuoda sinulle tämän perusajatuksen.

Miksi Breeze ei tule oletusarvoisesti?

Aloitan selityksellä siitä, miten ikkuna-koristeet toimivat KWin 4: ssä. KWin on niin kutsuttu ikkunaohjaajien uudelleenkäyttäminen. Tämä tarkoittaa, että X11: n hallitsema ikkuna laitetaan toiseen X11-ikkunaan, joka tarjoaa ikkunakehyksen. KWinissä käytämme ikkunakehykseen QWidgetiä. Siksi olemme rajoittuneet myös siihen, mitä QWidget tarjoaa meille ... Ratkaisumme on siepata kaikki koristemaalaustapahtumat QWidgetissä ja tukahduttaa se, laukaista säveltäjän maalaus ja taata renderointivaiheessa väliaikaisen kuvan koristelu, joka sitten kopioidaan tekstuuriksi.

Breeze-teemaikkunakoristelu perustuu Aurorae-teeman moottoriin. Koska olen Aurorae-lehden pääkirjoittaja, voin lyödä sen tähän blogikirjoitukseen tuntematta siitä pahaa 🙂 Aurorae on suunniteltu siten, että on erittäin helppo luoda koriste ja käyttää uusia läpikuultavuusominaisuuksia. Koska se on ratkaisu, jota voidaan käyttää oletuksena koristeena, mutta se ei koskaan ollut heidän tavoitteensa. Ajatuksena oli antaa käyttäjille, jotka haluavat räätälöinnin, tämä ominaisuus, kun taas suurin osa käyttäjistä voi käyttää nopeampia natiiviteemoja. Aurorae ei ollut koskaan nopea eikä tule olemaan nopea.

Nyt KWin 5: ssä QML: n käyttö on tärkein ongelma, joka tekee Aurorae-laitteista vaikean. QtQuick käyttää Scenegraphia ja käyttää QWindowsia QWidgetin sijaan. Se on QWidget-pohjaisen sovellusliittymämme suosikki. Muutimme sisäistä käyttöä tukemaan QWindows-pohjaisia ​​koristeita, mutta se oli melko vaikea tie, koska ikkunoiden käyttäytymisessä on eroja. Koska se ei enää perustu QWidgetiin, maalitapahtumien ansamme on rikki ja tarvitsimme siihen uuden ratkaisun. Ja tämä ratkaisu on edes ruma kuin edellinen, koska QtQuick työskentelee parhaillaan OpenGL: n kautta. OpenGL Qt -sovelluksen rajoitusten vuoksi (voidaan käsitellä Qt 5.4: ssä), joita emme voi jakaa QtQuickin käyttämän OpenGL-kontekstin kanssa ... Tämä ei ole vain valtava yleiskustannus, kun kopioimme sisältöä GPU: sta RAM-muistiin ja takaisin GPU: lle menetät myös paljon muistia. Suurennetun ikkunan tapauksessa se ei ole vain otsikkorivi, vaan koko ikkuna. Ja jokaisessa ikkunassa on tuo yläraja.

Pelkästään se voi tehdä Auroraesta täysin käyttökelvottoman. Käytän tällä hetkellä Breeze-teemaa ja KWin tarvitsee yli 200 Mt RAM-muistia - ei oikeastaan ​​hyväksyttävää. Mutta tilanne on vielä pahempi. QWindowsin avulla emme voi tietää, mitkä alueet päivitettiin. Joten kun esimerkiksi painiketta päivitetään, meidän on maalattava koko ikkuna, mukaan lukien täydellinen kopio koristelusta. Erityisesti animaatiotilanteissa on suuri ongelma.

Joten mikä on tie eteenpäin? Aloin toteuttaa uuden koristelun API: lle poistamalla hyvinvointipohjaisen koristelun rajoitukset QWidgetistä ja samaan aikaan aloin toteuttaa Breeze-koristeita tällä uudella API: lla. Toivottavasti voimme ottaa tämän käyttöön KWin 5.1: ssä.

Ja niin asiat ovat, herrat. Toivon, että ymmärrät enemmän tai vähemmän ongelman. Kysyn Martinilta, eikö ole käytännöllisempää ja nopeampaa tehdä natiivi Breeze-teema, kuten Happi, vaikka en ole tällä hetkellä huolissani, Happi, vaikka se ei olekaan ihanin asia maailmassa, sillä on paljon vaihtoehtoja ..