No pár let na Xorg ještě vydržím a pak nevím no. Zkoušel jsem nedávno zase na chvíli nahodit na více počítačích Wayland a i když je to lepší než před dvěma lety tak pořád je to proti Xorg šnek a vše je jak kdybych se přesunul v čase o 20 let zpět. Okna se otevírají všechny na hlavním monitoru namísto kde byli posledně, když kliknu pravým tlačítkem téměř v jakékoliv aplikaci tak se rozbalí nabídka klidně i na jiném monitoru než jsem. Celkově je to takové trhané a nepředvídatelné. No snad jen doufat že to za pár let bude lepší. Zatím je to pro mě hodně daleko od ideálu.
Podle mě otevírání oken je záležitost kompozitoru. Je na něm, aby určil, kde se má okno otevřít. Wayland už jen neumožňuje, aby si to určila sama aplikace, která to popravdě nikdy neměla mít možnost dělat.
Jinak nějaký výkonnostní problém jsem na Waylandu neviděl. Sám denně používám dva 4K monitory na několik let staré integrované notebookové GPU od Intelu a běhá to svižně.
A jak kompozitor ví, kde zobrazit okno podmenu?
> RRR
> ...když kliknu pravým tlačítkem téměř v jakékoliv aplikaci tak se rozbalí nabídka klidně i na jiném monitoru než jsem
Jinak výkonnostní problémy vidím na starém PC taky. Všiml jsem si, že když otevřu náročnou aplikaci (třeba Teams), tak i když je v pozadí, celý desktop spadne ze 60 fps na 30 fps (VSync). Když ten Teams minimalizuju do ikony traybaru*, tak se zvedne fps desktopu na plných 60. Nejlepší je, že ve fps desktopu je i kurzor myši, takže si člověk vzpomene, jak se trhal kurzor ve Windows 9x, kde jel asi na 40 Hz.
*) Použil jsem wrapper na webový Teams, protože desktopová verze v Electronu už pro Linux není. Ale funkčně i technicky je to jedno.
18. 9. 2025, 21:22 editováno autorem komentáře
Ubuntu 24.04.3 LTS Gnome 46
Intel Core i7-6700 × 8
32,0 GiB RAM
NVMe SSD
Intel HD Graphics 530 (SKL GT2)
Na Xorg je to fičááák. Na Waylandu je to chvíli rychlé a někdy urkutně trhané i když není nic puštěné, třeba pokud rychle přejedu myší přeš tři monitory tak vizuálně myš zůstane na všech monitorech. Pokud pominu tuto věc což třeba mohu přičítat tomu že je Wayland prostě nenažraný a vyžaduje nejmodejrnější HW tak mi také vadí již popisovaná nemožnost si zapamatování kde a v jaké velikosti se jaká aplikace má otevřít. Na Xorg je to tak že pokud nějakou aplikaci dáte otevřít na polovině levého monitoru tak při příštím spuštění se otevře zase tam.
Rád bych se i rozpovídal o bordelu v aplikacích kdy třeba Flameshot funguje katastrofálně a také mě štve že hromada aplikací neumí na Waylandu používat dekoraci oken systému z GTK a začne používat nějaké základní a pak máte v jednu chvíli třeba tři aplikace pokaždé s jinou dekorací okna. Na Xorg je vše takové hezčí a vypadá to vše stejně. Ano já vím zase začnete spívat tu písničku že je to chyba vývojářů onech aplikací, pak ještě to jak všichni obhajují Wayland že když něco nejde tak je to vlastně pro dobro uživatele a to že to na Xorg fungovalo je bezpečnostní chyba a ať je uživatel rád že to Wayland milostivě vyřešil za ně.
Zatím nevím o ničem co na Waylandu funguje lépe než na Xorg?
19. 9. 2025, 10:21 editováno autorem komentáře
Tak třeba podpora HiDPI je na Xorg pro mě těžko použitelná. Na rozdíl od Waylandu, kde je v tomto ohledu problém jen s aplikacemi, které běží na XWaylandu, opět kvůli omezením Xorgu.
A pak třeba tearing. Tuhle věc, s kterou jsem měl na Xorg bohaté zkušenosti, na Waylandu prostě neznám.
19. 9. 2025, 12:07 editováno autorem komentáře
Já používal monitory s různým DPI už v dobách Ubuntu s Unity desktopem, to je víc jak dekádu zpět. Ano, řešilo to desktopové prostředí a ne X11, ano, Canonical musel napsat patch pro Firefox (který nekreslí přímo přes Gtk nebo Qt, kde je to v základu), ale uživatel nainstaloval nejběžnější Linux distro a vše jelo, jak má. Ono v tom Waylandu to taky musí řešit desktop, resp. jeho kompozitor, proto v každém DE funguje něco jiného a něco zas ne.
I v XWaylandu funguje HighDPI, Fedora to používá(la) pro Chrome(ium), když tam ještě nebyla dobrá podpora Waylandu. Bohužel tohle je velká chyba Linuxu, že nic není jednoduše uživatelsky nastavitelné. Ve Windows a macOS jako uživatel kliknu pravým tlačítkem na aplikaci a můžu přebít chování. Např. app umí HighDPI, ale jen do 125 % (protože ten už byl ve Windows 3.1 v roce 1992) a já mám monitor se 125 % DPI (např. typický 14-15" laptop s FullHD displejem). Tak řeknu Windows, ať app zobrazí v plném rozlišení, že vím, že to app zvládne (do tohoto DPI). Nebo naopak app hlásí, že HighDPI umí, ale třeba nezvětší toolbar buttons nebo některé méně používané dialogy - vynutím, ať ji kreslí v DPI 100 % a upscaluje jako obrázek.
Samozřejmě, že absenci schopnosti Xorg škálovat různě na různých monitorech lze obejít nějakou implementací na úrovni desktopu nebo aplikace. Problém těchto řešení je, že jsou prostě rovnák na ohejbák a nikdy nefungovaly plnohodnotně. Ostatně jako další jiné pokusy, které se snaží roubovat moderní funkcionalitu na 40+ let starý design Xorg. Na Waylandu připojím k notebooku s 320 DPI externí monitor se 180 DPI, všechno se správně naškáluje včetně neceločíselného škálování, okna všech aplikací se dynamicky přeškálovávají, když je přesunuju mezi monitory... Tohle nikdy na Xorg dobře nefungovalo a už ani nikdy nebude.
Právě že ne, je potřeba upravit aplikaci. Např. ji přepsat do Waylandu. Půlka se přepisovat nebude, některé čekají na chybějící funkcionalitu, která se posupně doplňuje (naposled pozicování child oken, např. vysouvacích menu v klasických aplikacích).