Stacking vs. compositing window managers - wat is sneller?

[Sando]

Metacity (GNOME 2), Mutter (GNOME 3/Meego) en Xfwm (Xfce) zijn compositing window managers. *Box zoals OpenBox (LXDE) zijn stacking window managers.

Voor mijn gevoel en begrip zijn compositing WM's optimaler en sneller, omdat de stacking WM's als het ware de boel intern compositen (= slechte uitleg voor stacken) en dan softwarematig uitrenderen naar het beeld.

Toch zijn *Box WM's de beste keus voor snelheid. Heb ik dat goed begrepen? LXDE schijnt de lichtste Ubuntu-distro te zijn, en ik merk dat deze op mijn antieke laptop ook sneller is. Maar heeft de WM daar ook een vinger voor in de pap? Gevoelsmatig is dat stacken namelijk juist een extra stap.

Ik heb bijvoorbeeld een lichte HTPC met een APU. Accelerated graphics worden alleen ondersteund door compositing managers, en dat klinkt als reden #2 waardoor compositing > stacking. Toch als ik een live-cd van Lubuntu probeer op mijn Xubuntu-HTPC, lijkt het allemaal sneller te gaan. En dan vraag ik me af, komt dat puur door services en meuk, of heeft de WM daar wel degelijk wat mee te maken? Ik heb er wel geen stopwatch bijgehouden, maar het verschil is volgens mij te aanzienlijk om een gevalletje placebo-effect te zijn.

Want voor de snelheid wil ik best naar OpenBox gaan, maar als het puur om services en meuk gaat blijf ik het liefst bij Xfwm of als het toch niet uitmaakt vind ik Compiz wel handig.

Ik heb ook gelezen dat het mogelijk is om Compiz met LXDE aan de praat te krijgen. Dan heb je wel een mooie compositing WM en toch de services en meuk van (de lichte) LXDE. Voordat ik de boel ga herinstalleren ben ik benieuwd of iemand met beter inzicht kan uitleggen of er op deze manier feitelijk voor- of nadelen aan het ene of het andere type WM zitten.

[Katsunami]

Volgens mij haal je wat dingen door de war:

Wikipedia over de stacking window manager:

A stacking window manager (also called floating window manager) is a window manager that draws all windows in a specific order, allowing them to overlap.

Dit betekent slechts dat vensters in een stacking window manager elkaar kunnen overlappen.

Dit in tegenstelling tot een tiling window manager:

In computing, a tiling window manager is a window manager with an organization of the screen into mutually non-overlapping frames.

Wikipedia over de compositing window manager:

A compositing window manager is a type of window manager (software that draws a graphical user interface on a computer display), that unlike earlier window managers which made each individual program responsible for rendering its own window directly inside the display memory, provides applications an off-screen buffer for window memory and composites windows into an image representing the screen and writes the result into the display memory.[1][2]]

Dit betekent dat alle vensters door de window manager off-screen worden gerendered (en niet on-screen, door elk programma apart) en dan allemaal tegelijk op het scherm worden gekwakt. Meestal gebeurt die rendering in de hardware, maar een composited window manager kan ook gewoon volledig in software renderen natuurlijk.

stacking / tiling (wel / niet overlappen) en compositing (renderen in een buffer) hebben dus volgens mij totaal niks met elkaar van doen. Omdat vensters elkaar niet overlappen in een tiling manager, kunnen de renders dus sneller zijn.

Wel denk ik dat een composited stacking window manager die off-screen via een beetje fatsoenlijke grafische kaart rendert sneller zal zijn dan een niet-composited tiling window manager.

edit: daarom is het ook een farce om onder Windows 7 te zeggen: zet Aero uit en gebruik de classic interface, want dat is sneller. Dat is onzin. Windows XP, Vista en 7 gebruiken alle 3 een compositing window manager (Windows regelt namelijk de vensters, niet elk programma apart), met het grote verschil dat XP de compositing in software doet, en Vista / 7 via de grafische kaart.

Windows Vista / 7 terugzetten naar de classic interface zonder Aero zal dus je computer alleen versnellen als je een *hele snelle* CPU hebt, gecombineerd met een *hele trage* grafische kaart.

Ik denk dat de verwarring is ontstaan omdat Compiz zo uitgebreid is begonnen te praten over een "Compositing 3D Window Manager" (via de grafische kaart), waardoor mensen denken dat een window manager die niet via de grafische kaart gaat automatisch niet-compositing is. Zelf denk ik dat bijvoorbeeld XFCE het zelfs fout heeft in zijn dialoogvenster "Window Manager tweaks". Daarin zit een optie "Enable Compositing". Wat ze volgens mij bedoelen is "Enable rendering via GPU".

[ Voor 38% gewijzigd door Katsunami op 03-04-2012 00:43 ]

[CAPSLOCK2000]

Met Katsunami. Het gaat over verschillende aspecten die niks met elkaar te maken hebben.

[BoAC]

Katsunami schreef op dinsdag 03 april 2012 @ 00:30:
.. Zelf denk ik dat bijvoorbeeld XFCE het zelfs fout heeft in zijn dialoogvenster "Window Manager tweaks". Daarin zit een optie "Enable Compositing". Wat ze volgens mij bedoelen is "Enable rendering via GPU".

Je spreekt jezelf tegen. Compositing betekend alleen dat er ofscreen door de apps gerenderd wordt en dat de composite manager de werkelijke screen rendering doet (al of niet via GPU) :-)

[Katsunami]

Nee, ik spreek mezelf niet tegen; niet zover ik weet.

Compositing betekent inderdaad dat de window manager de rendering doet, en niet de applicaties zelf. Zover ik weet zijn alle window managers in Linux (en ook in Windows) al heel lang compositing managers, al renderden ze vroeger allemaal via software.

De window manager van XFCE is volgens mij altijd al een compositing manager, onafhankelijk van de setting "Enable Compositing"; wat die optie doet is de rendering via de GPU laten lopen. Er worden ook een aantal opties beschikbaar die alleen snel genoeg kunnen werken via een GPU, zoals transparantie; in software is dat veel te traag.

Ik denk dat zeer veel mensen (en documentatie) de term "compositing window manager" gebruiken als ze eigenlijk "GPU rendered window manager" bedoelen. Volgens mij is die verwarring door Compiz veroorzaakt, omdat men daar specifiek sprak van een "3D compositing window manager" en er nadruk op legde dat deze via de GPU werkte. Daardoor zijn velen (denk ik) "compositing" gelijk gaan stellen met "werkend via de GPU", wat niet per se zo hoeft te zijn.

[ Voor 18% gewijzigd door Katsunami op 03-04-2012 10:28 ]

[Sando]

Als ik Katsunami's verhaal lees is dat wel hoe ik het ook begrepen had.

Waardoor jullie vermoedelijk denken dat ik het door de war haal is dat ik zei: intern compositen (= slechte uitleg voor stacken) maar ik bedoel eigenlijk het zelfde. Of de verschillende vensters nou offscreen gemaakt worden en onscreen tot één beeld gevormd worden, of direct bottom-to-top onscreen getekend worden, het effect wat je krijgt noem je nu eenmaal compositen. Mijn probleem is waarschijnlijk dat ik compositor ben en veel met after effects werk, en snel vanalles compositing ga noemen.

Ik snap ook dat compositing niet perse hardwarematig gebeurt. Je kan immers XFCE en Gnome2 ook op computers zonder hardware support draaien. Maar ik ging er gemakshalve wel even van uit dat je bij een compositing WM wel de hardware support aanhebt. (Zoals jij in de laatste alinea van je laatste reactie ook een goed punt hebt.) Dat gebeurt immers vrijwel altijd automatisch tegenwoordig. Maar bij stacking is dat dus niet eens mogelijk. Dat is mijn hele punt van "onlogisch gevoelsmatige prestatiewinst" bij de stacking WM (OpenBox) die ik testte.

Je volgende comment slaat denk ik de spijker op de kop:

Katsunami schreef op dinsdag 03 april 2012 @ 00:30:
als je een *hele snelle* CPU hebt, gecombineerd met een *hele trage* grafische kaart.

want hoewel je het over Windows hebt denk ik dat dit toch de meest logische uitleg is van toepassing op WM's. Omdat de CPU in weinig gevallen op kan boksen tegen de GPU, alhoewel ik een APU heb, zou compositing (mits hardwaresupport enabled) altijd een betere keus zijn.

Het distro snelheidsverschil wat ik merk zou dan toch vooral met overige services en meuk te maken hebben, niet zozeer met de WM. (OpenBox vs Xfwm)

[CAPSLOCK2000]

Ik vind het maar erg moeilijk te volgen. Het woord 'stacking windowmanager' heeft een duidelijk gedefinieerde betekenis, en dit is het niet.
Compositing is een techniek die niet veel met snelheid te maken heeft. Maar als je compositing op je graca kan doen hoeft je CPU het niet meer te doen. Sommige dingen kan de graka veel sneller. Dan moet je die dingen wel doen.

Je vraagt een beetje "wat is sneller, 4 wiel-aandrijving of een koelbox met twee wielen?". Naast dat de terminologie niet klopt, zoals je nu wel door zal hebben, is de vraag niet met "ja" of "nee" worden beantwoord. 4wd is sneller als je door het bos moet, op de snelweg heb je er niet veel aan en ben je waarschijnlijk langzamer (door het extra gewicht).

Op moderne hardware is compositing sneller mits je aan grafische effectjes doet. (alt-tab is ook een soort effect). Als je dat toch allemaal niet doet, zoals XFWM, hoef je er ook geen tijd aan te verspillen.

[Katsunami]

Je haalt volgens mij nog steeds dingen door elkaar.

Stacking = overlappende vensters
Tiling = niet-overlappende vensters

Composited = off-screen rendering door de window manager
Non-Composited = on-screen rendering door de apps zelf

Dat is alles. Een stacking WM kan dus óf composited zijn, óf non-composited; dat heeft *niks* met snelheid te maken, maar met de manier van vensters opbouwen (off-screen, of on-screen). En of je nu wel of niet aan compositing doet maakt niet uit voor de rendering: die kan wel, of niet via de GPU gaan.

Tegenwoordig is eigenlijk bijna elke WM composited (dus off-screen), anders zou je de vensters letterlijk op het scherm opgebouwd zien worden. Dat kon onder Windows 3.1 bijvoorbeeld gebeuren: dan zag je een venster "afrollen" op een trage computer. Dat komt niet echt meer voor zeg maar.

De nieuwste composited WM's zoals die van Vista, 7 en Compiz, Gnome3, xfwm4, Kwin zijn echter *naast* het feit dat ze composited (off-screen) zijn, ook nog accelerated (via de GPU). En ze zijn ook nog stacking (met overlappende windows)

Die termen moet je goed uit elkaar houden.

Sando schreef op dinsdag 03 april 2012 @ 17:44:
alhoewel ik een APU heb, zou compositing (mits hardwaresupport enabled) altijd een betere keus zijn.

Wat je hier waarschijnlijk bedoelt is dat een window manager via de GPU altijd het beste is. Dat is waarschijnlijk ook zo.

Stel, je hebt een hele trage grafische kaart, en tegelijkertijd heb je een hele snelle CPU. Als je dan een zware window manager draait via de grafische kaart (Compiz bijvoorbeeld), dan kan die trager zijn dan een simpele window manager (OpenBox) via de CPU. Echter, een béétje grafische kaart van tegenwoordig is snel genoeg om zelfs met de zwaarste window manager een simpele niet-accelerated window manager eruit te blazen qua snelheid.

[ Voor 33% gewijzigd door Katsunami op 03-04-2012 20:03 ]

[Sando]

Nee, met deze laatste post wordt het er niet helderder op. Ik voel me opeens zekerder van mijn eerste post. Volgens mij gebruiken we nu allebei semi-foute terminologie terwijl we hetzelfde bedoelen.

• Álle gebruikelijke (Linux/X) WM's zoals we ze kennen hebben overlappende vensters. (Behalve Windows 1.0, die is tiling. En ironisch genoeg Metro van Windows 8, die is ook tiling.)
• Toch heb je duidelijk onderscheid tussen
  • stacking WM's (Fluxbox, OpenBox, Blackbox), en
  • compositing WM's (Metacity, Mutter, Xfwm, Compiz).

Op trage hardware zijn stacking WM's beduidend sneller dan compositing WM's, dus er is wel degelijk een verband met de snelheid.

Alleen dat je een compositing WM moet gebruiken om hardwareversnelling** in te kunnen zetten, zoals Capslock2000 zegt, geeft aan dat deze CWMs op modernere hardware sneller zijn omdat zij een stuk clockcycles kunnen offloaden naar de GPU, en SWMs niet.

edit:

**) Door jou aangegeven inderdaad soms verwarrend enable compositing genoemd

Zo zit het met de afgelopen (huidige generatie*) WMs in Linux. Niet dat ik dat al wist, maar met de post van Capslock2000 en Wikipedia naast elkaar meen ik het op deze manier te begrijpen.

*) Met steeds pienterdere grafische kaarten komt daar inmiddels verandering in want ik neem aan dat die Tiling grapjes van Metro gewoon lekker hardwareversnelling genieten.

[ Voor 3% gewijzigd door Sando op 03-04-2012 23:52 ]

[Katsunami]

Het is wel zo dat je een compositing window manager moet gebruiken om hardwareversnelling te kunnen hebben ja. Je kunt (op dit moment) volgens mij niet én tegelijkertijd elk programma op het scherm laten renderen én aan hardwareversnelling doen.

Het is echter niet zo dat een stacking WM composited, of hardwareversneld MOET zijn. De WM van Win3.1 was stacking, maar niet composited, en niet versneld. De WM van XP was stacking, composited, maar niet versneld. De WM van Vista en 7 zijn stacking, composited én versneld.

Tevens is er ook geen reden waarom een tiling composited window manager niet zou kunnen bestaan. Zoals je al zegt ben ik er bijvoorbeeld van overtuigd dat Metro's tiling WM én composited én hardware-versneld is.

Op trage hardware zijn stacking WM's beduidend sneller dan compositing WM's, dus er is wel degelijk een verband met de snelheid.

Nogmaals, stacking en compositing hoeven elkaar niet uit te sluiten. In tegendeel. Een stacking WM heeft *veel* meer te berekenen dan een tiling WM vanwege de overlappende vensters. Indien je een WM genaamd X hebt, en je zet compositing (en daarmee ook de hardware-versnelling) uit, dan zal dat alleen snelheidswinst opleveren als je grafische kaart uitermate lam, en je CPU bruut snel is.

[ Voor 7% gewijzigd door Katsunami op 04-04-2012 00:40 ]

[Sando]

We zijn het in grote lijnen met elkaar eens, maar waar je zegt dat een stacking WM wel of niet compositing kan zijn, heb je het volgens mij toch fout. Volgens mij wikipedia is het duidelijk de één of de ander:

Wikipedia: Comparison of X window managers zie Type 4e kolom

Ook haal je steeds Tiling erbij terwijl die in deze vergelijking eigenlijk niet thuis hoort omdat het een andere soort (voor de end user) WM is. Volgens mij verwar je stacking met tiling, compositing met stacking, en hardware-acceleration met compositing, hoewel je eerder aangaf dat men juist voor deze valkuil moet oppassen, want dan klopt het precies wat je zegt:

Compositing en hardware-acceleration hoeven elkaar inderdaad niet uit te sluiten, maar stacking en compositing juist wel want dat zijn gewoon twee verschillende methodes om het scherm op te bouwen. Tiling heeft hier verder niets mee te maken en kunnen we buiten beschouwing laten, omdat het niet met vensters werkt zoals de 50* populairste WMs.

offtopic:
*) Dit is een verzonnen statistiek.

[ Voor 67% gewijzigd door Sando op 04-04-2012 08:10 ]

[MacGrumpy]

om olie op het vuur te gooien, mijn openbox is ook compositing. (m.b.v. cairo composite manager)

Zoals al eerder is aangegeven, compositing (zoals de term gebruikt word in linux WM's) heeft te maken met het offscreen/onscreen renderer van vensters.
Het heeft verder niets te maken met acceleratie (1) of de manier van vensters rangschikken. (stacking vs tiling vs whatever)

Je kan dit eenvoudig zelf controleren, maak een applicatie die expose events aangeeft.
Als je een non-compositing window manager draait zal deze expose events geven als je een ander venster er over heen beweegt. Het programma moet zelf het gedeelte opnieuw tekenen dat weer zichtbaar word.
Met een composite manager hoeft dit niet (want je beweegt niet de applicatie, maar het offscreen buffer over het scherm en je hertekend gewoon vanuit de offscreen buffer)

Aangezien wikipedia kendelijk de bron van alle waarheid is:
A compositing window manager is a type of window manager (software that draws a graphical user interface on a computer display), that unlike earlier window managers which made each individual program responsible for rendering its own window directly inside the display memory, provides applications an off-screen buffer for window memory and composites windows into an image representing the screen and writes the result into the display memory.

Welke nu sneller is hang van de implementatie af:
de klassieke manier zal minder geheugen gebruiken (geen extra offscreen buffer nodig) en minder memory copies. (afhankelijk van implementatie).

Echter zal bij het bewegen van schermen over elkaar heen de applicatie opnieuw de GUI moeten tekenen, wat (again afhankelijk van implementatie) veel rekenwerk kan kosten (b.v. een grafiek word vaak volledig opnieuw getekend, ook al is alleen het hoekje 'beschadigt').

Op moderne hardware en met toolkits die complexe gradients e.d. hebben (die veel tijd kosten om opnieuw te tekenen) zal het aan staan van compositing vaak sneller zijn als je vensters heen en weer beweegt, tussen workspaces schakelt, etc.

Compositing is een OPTIE van een WM, zoals het ondersteunen van 'on-top' vensters.

p.s. stacking slaat op hoe vensters op het scherm qua ordering (overlapping, etc), compositing over hoe 'achter de schermen' de INHOUD van vensters gerendered worden. De twee begrippen staan dan dus ook volledig los van elkaar. Je kan compositing zijn en stacking of compositing en tiling of niet compositing en stacking. In bovenstaande quote van wikipedia word stacking ook niet genoemd.

1) het is met de compositing strategie wel makkelijker om effecten toe te passen op WM acties.

[ Voor 8% gewijzigd door MacGrumpy op 04-04-2012 09:09 . Reden: typos ]