Igazából a Wayland-en működő WM-ek nem kompozitorok, csak úgy nevezik őket. Nem olyan értelemben kompozitálnak, ahogy X alatt szokás. Elég szerencsétlen nevet adtak neki. A Wayland sokkal közvetlenebbül kezeli a videóhardvert, nincs ott mögötte a szerver-kliens bonyolítás, hanem mindent közvetlen eléréssel valósít meg.
Az X kirajzolásánál lehet én értettem félre valamit régen, bár az is igaz, hogy annyi mindent összehordasz, hogy nehéz követni, meg emlékezni rá. Akkor legyen a Qt, Gtk kirajzolása lassú, az gondolom a szoftveres komplexitás miatt van, gyenge hozzá a procid, ami nem csoda, 17 éves gép, és a maga idejében sem volt egy erőmű, nincs rajta csodálkozni való, azon a böngészők is épp ugyanezért vánszorogni fognak, meg minden, ami webes.
A Qt-s libek előtöltésénél nem a prefetch-ről beszélek, hanem a dinamikus linkelésről, mint a Windows alatt a dll-ek. Ott is ha egy dll-t betöltött egy bizonyos program, és utána indítanál még többet, ami szintén ugyanazt a verziójú, fájlnevű dll-t használja, az nem tölti be még egyszer, hanem használja a már memóriában lévőt. Shared lib a pontos neve. Neked ez különösen előnyös lenne, mert ha az LXQt betölti, akkor ilyen zenelejátszók, amiket annyira szeretsz, már nem töltik be még egyszer, és nem kell fujjolnod, hogy bloat. Prefetch-el Linux alatt nem szórakoznak, az a lassú IDE/SATA meghajtók és a lassú NTFS okozta szűk keresztmetszet megoldására született.
A fejlesztő meg persze, hogy jó gépet vesz, mert minél gyorsabban tölt be az IDE, debugger, minél gyorsabban fut a compiler, interpreter, azzal időt nyer. Ez azonban nem jelenti azt, hogy a kész szoftver működéséhez is ugyanolyan combos gép kell. Igazából a legbabzsákabb fejlesztők már nem is 8 magos workstation-ön nyomják, hanem 64-128 magos build szerveren, amiben van 128-256 giga RAM legalább, óriási projekteket, mint a Linux kernel, böngészők, LLVM, gcc, LibreOffice azon szoktak fordítani. A 8 mag, 16-32 giga az átlagos inkább ma már, azon lenne egy komolyabb projekt egyszeri forgatása min. 2 óra.