Názory k článku GNOME 42: začal přechod na GTK 4, část aplikací už byla portována

Ten screenshot v úvodu článku, to je nějaká aplikace pro nejmenší :) ?

gnome-software

To je nejhůř fungující věc z celýho slavnýho Gnome.

Na čerstvě nabootovaným systému to nějak jede, ale po víc jak 12h uptime při spuštění načítá.... a načítá... a načítá... a nic se neděje, po 15 minutách mi dojde trpělivost. Naštěstí je tam vyhledávání.
Po uspání a probuzení přestane ale fungovat vyhledávání. Takže buďto můžu instalovat z GUI, ale musím před tím restartovat kompl (připomínám, že jeden ze silných důvodů emigrace z widlosvěta byly restarty), nebo osvědčený DNF v terminálu.

Ale nikoho to netankuje, hlavně že za poslední rok 2x změnili vzhled a jednou framework. Musí to vypadat cool, že to nefunguje je šumák...

(Fedora 35 na HP6560b, 480GB SSD, 8GB RAM)

Jedno to určitě nikomu není. Třeba v této verzi byl kompletně přepsaný threading model, který by měl s těmito věcmi hodně pomoct. Nicméně největší brzdou GNOME Software je momentálně PackageKit, který už je ve stavu hluboké údržby a nic většího se v něm neděje. Dokud nevznikne DNF backend používající libdnf, který ho nahradí, tak některé problémy při práci s balíčky (ne ostatními formáty jako flatpak, ostree...) budou přetrvávat.

S fractional scaling sa bude niečo diať?

V experimentálnom štádiu je to od roku 2017. Za 5 rokov sa to už mohlo dotiahnuť. Namiesto toho sú X11 aplikácie stále rozmazané, aj tie, ktoré v xorg session zvládajú HiDPI.

29. 3. 2022, 10:56 editováno autorem komentáře

Pochybuji ze se s X11 bude vubec neco delat - nejsou lidi.

On je to problém Xwaylandu, tvrdí každej aplikáciíí, že ide s 96 dpi a potom to rozmaže na skutočnú veľkosť. Problém je, že robí upscaling. Keby robil downscaling (t.j. povedal aplikáciam, že maju 192 dpi a nech bežia v HiDPI @2X), nebol by problém. A že ide o Xwayland? No, bohužiaľ, stále veľa aplikácií je len X11, a Chrome/Elektron ešte len pridáva k problému.

A vďaka tomu si stále väčšina používateľov myslí, že "Linux nepodporuje HiDPI".

Popravdě nevím, jak se to vyvíjí. Samozřejmě to může být lepší, třeba tím, že aplikacím dáte 200 % na vykreslení, ale neceločíselné škálování nebude nikdy úplně dobře fungovat a nefunguje ideálně na žádném systému.

Škálování na 150 % se i u aplikací na Waylandu dosahuje tak, že se je nechá škálovat na 200 % a pak se ta bitmapa zmenší na 150 %. Není to apriori rozmazané, ale zase to vytváří drobné artefakty a deformace, takže se na to aplikuje vyhlazování, čímž člověk o tu ostrost zase přichází. Některé frameworky škálují vektorově a pak můžou škálovat přímo na libovolnou hodnotu, ale to nefunguje plošně, takže kompozitor bude asi napořád dávat aplikacím celočíselné škálování a pak to doškálovávat. To má samozřejmě efekt i na výkon.

Já už jsem nad tím zlomil hůl. Držím se celočíselného škálování a kde to potřebuju trochu zvětšit/zmenšit, dělám to přes škálování písma. Na domácím notebooku mám DPI 160, 100 % je moc malé a 200 % moc velké, tak jsem nechal 100 % a zvětšil písmo na 115 %. Není to ideální, ale výsledek je IMO mnohem lepší než neceločíselné škálování. Jediné pořádné řešení je na straně hardwaru. Pořizovat si monitory, které neceločíselné škálování nepotřebují. U externích monitorů to znamená přeskočit 4K s pseudoHiDPI a používat 5K, což uznávám zatím za rozumné peníze není.

Jo, všechny ty 23,8" 4k LCD nikdy nebudou mít optimální ostrost při optimální velikosti GUI. Buď 4k ve 100% velikosti, tedy titěrné prvky, nebo 200%, což to degraduje na FullHD. Cokoli mezitím nikdy nebude "řežavě ostré", protože prostě nikdy pro nějaké float škálování nebudou přepsány všechny X11 aplikace, co se jich za těch skoro 40 let urodilo. Kdybych měl kupovat 4k monitor, tak prostě jdu do aspoň 32", pokud bych to na fotky či video opravdu potřeboval/chtěl. Jinak je to nerozum, to raději 27" 2560×1440.

Taká hlúpa otázka: používate vôbec hidpi monitor?

Ono totiž pointa nie je mať väčší desktop; pointa je mať ostrejší. To, že je niečo v 150-200% stále bude "řežavě ostré" v porovnaní so 100% low dpi, pretože tam, kde ste predtým mali jeden pixel teraz pracujete so štyrmi. Aj pri 1440@2X na 4K ste na tom lepšie a ostrejšie, ako s natívnym 1440p. Natívne rozlíšenie je lepšie len pre hráčov hier.

32" 4K je veľmi nešťastná kombinácia veľkosti a rozlíšenia, je to nejakých 138 dpi. Ani hidpi, ani low dpi.

No samozřejmě že pointa není mít větší desktop. Jen konstatuji, že (například mě) vyhovuje fyzická velikost prvků GUI, kterou při standardní hodnotě 96 dpi dávají W10, stejně jako GNOME či KDE atd. Čili jsem nikdy neměl problém s 20" 1680x1050 i 20" 1400×1050 či 24" 1920×1200 a 27" 2560×1440. 21,5" 1920×1080 taky ještě OK, ale třeba 23,8" 4k už je naprd, tam to chce 200% dpi, čili jak píšete, člověk získá ostřejší/jemnější zobrazení. Jenže to je celočíselné. Takových 4k na 27"/28" displeji je o něčem jiném. Ono i 32" 4k je méně příjemné (měl jsem to před X lety v rámci testu nějakého duálního Radeonu), chtělo by to spíš tu 43" obludu. Proto zatím na 4k nejedu, spíš vyčkávám a čas od času kontroluji, kam se tohle neceločíselné škálování podaří dotáhnout. Ostatně můj stařeček (27" WUXGA Dell IPS) stále funguje a na fotky si těžko představit něco lepšího v rozumné cenové hladině, takže nespěchám.

Za mna je ideal 125 pri nastaveni 96, po skusenosti s 12.1" laptopom. Je to ostrejsie nez original a stale citatelne.

IMHO jedna z chýb bola fixácia na presné "percentuálne" veľkosti. Je tu totiž jedna implementácia, ktorá to nerobí a funguje dobre: Apple v iOS a macOS.

Ona tiež nechá aplikácie kresliť na 200/300%, potom ich downscaluje a nemá drobné chyby s artefaktami ani deformáciami. Robí to trocha inak ako Mutter: urobí väčší framebuffer (Mutter skladá surfacy do framebufferu s rovnakým rozlíšením ako je displej) a tento potom celý downscaluje pomocou output enkodéra (nie GPU a textúrami! output enkodérom, takže zmenšenie je "zadarmo" pri scanoute framebuffera. "Cenou" je vyššia spotreba VRAM pre framebuffer). Nie je to vo fixných 25% krokoch, ale tak, aby sa minimalizovali artefakty.

Príklad: displej má rozlíšenie 2560x1600, vytvorí sa framebuffer pre rozlíšenie 2880x1800. Sem sa kreslí s 200% a na výstupe každých 9 pixelov z fb je možné vykresliť 8 fyzickými na displeji. Akákoľvek chyba vznikne, je limitovaná na týchto 8 pixelov a nikam sa ďalej neprenesie. Cenou za to je, že Apple neponúkne mierku "175%", ale abstraktné "viac miesta" (a akému rozlíšeniu to zodpovedá). To, že je to 177,7778% nikoho reálne netrápi a kto si to nedá do kalkulačky, ani nevie. Tým, že Mutter trvá na presnej mierke vznikajú artefakty a pritom to reálne vôbec nikto nepotrebuje.

Samozrejme, niekedy vychádzajú aj pekné mierky: napríklad 2560x1440@2X na 4K monitore je presne 150%. Je to viacmenej ale náhoda a nedržia sa toho pre každý displej.

Podobne si treba dať pozor aj na spodnú hranicu: 125% znamená, že chcete kresliť 8 pixelov z framebufferu pomocou 5 fyzických. To samozrejme bude vyzerať zle. Preto je riešením takého niečo nepovoliť (alebo iba s výstrahou; Apple zvolilo riešenie - pre každé rozlíšenie displeja sú k dispozícii rozlíšenia framebuffera nadefinované tak, aby to bolo použiteľné), ale nie kvôli tomu zavrhnúť celý fractional scaling. Áno, konkrétne tento prípad je problematický pre 14" notebooky s Full HD displejmi, kde by bolo 125% ideál, ale to nikdy nebude vyzerať dobre (a Apple sa tomu vyhlo tak, že notebooky s takým displejom nemá. PC svet nemá tento luxus).

Takže ku koncu: problém sa dá teda riešiť aj softvérom, len s trocha iným postojom ako bol doteraz. Je škoda, že to bolo roky ponechané vyhnívať, pretože je to aktuálne veľká slabina, viditeľná bežnými používateľmi, ktorú treba riešiť. Určite s vyššou prioritou, ako v článku spomenutá persistent desktop session. To, že developeri Redhatu sa začnú vyhýbať HiDPI displejom, takým aké sú dostupné na trhu situáciu nezlepší, ale určite zhorší.

Ano, nejběžnější High DPI v PC světě (125 %) na macOS standardně nefunguje. Ale dá se to vyřešit softwarově (myslím něčím jako virtuálním monitorem - brácha si to zprovoznil na Air M1).

1. 4. 2022, 05:22 editováno autorem komentáře

Díky za pěkný popis, hezky napsáno, kvalitní novinářská práce. A dobrá programátorská práce :)

Ještě jsem tedy radši zůstal na 38, než se vše odladí, ale už se těším na upgrade. Ještě kdyby byla možnost dát lištu s programy nahoru místo dolů a bude to dokonalé.

S Tumbleweedem jedu zase nějakou dobu aktuální GNOME. Do 42 jsem tedy naskočil z 41.4 a nepozoruji žádnou zásadní visuální změnu, která by byla negativní. Jo, některé prvky vypadají trochu jinak, to je otázky týdnu-dvou než si zvyknu. Oceňuji, že jsou různé prvky visuálně přehlednější, třeba oddělenější položky v menu vpravo nahoře. Nový lehký Textový editor vypadá být fajn náhrada za Gedit, kde tu a tam něco kravlo (a hlavně nešlo Ctrl+kolečkem měnit velikost písma za běhu), od nějaké zkušební verze kdysi se to docela posunulo. Vypadá to, že v tom začnu psát jako v primární aplikaci, čili za mě fajn (akorát na Tumbleweedu bylo potřeba to ručně doinstalovat).

Z hlediska rychlosti nepozoruju žádnou změnu, ono akcelerace UI při velkých pohybech je u mě asi stejně limitována tím mnoho-letitým Radeonem, než čímkoli jiným :-). Takže já jsem v tuto chvíli veskrze spokojen (přitom mě dvě třetiny uvedených novinek vlastně vůbec nezajímají). Díky a jen tak dál!

ok, beru zpět, nový textový editor dělá stejnou nepříjemnost jako starý textový editor (čili gedit), tedy chyba bude v nějaké komponentě, kterou používají oba. Noco, takže zase KWrite (kterej konečně vypadá ok a tmavě v tmavém GNOME).

Oba používají GtkSourceView, takže v tomto se budou chovat hodně podobně.

Jak řeší to RDP? To si fakt naprogramovali něco nového svého, nebo zabalili nějaký hotový projekt? Poradí si to i s různým rozlišením na straně serveru a klienta podobně jako RDP ve Windows?

vypada ze neco sveho:
https://gitlab.gnome.org/GNOME/gnome-remote-desktop

Používá se gnome-remote-desktop, který ale jako backend používá FreeRDP.

Jenom k té kalkulačce, furt ještě počítá 48e12/6e6=8e18 ?