O HiDPI v Linuxu

Už několik měsíců mám Dell XPS 13, který má tzv. HiDPI displej. Ten má vskutku impozantní jemnost: 3200×1800 pixelů na 13,3″, což je hustota 276 pixelů na palec. Takové DPI je srovnatelné s mobilními telefony (Retina displej u iPhonu má 325 DPI). Jak si s takovými displeji poradí linuxový desktop?

tux

Na začátek je potřeba říct, že podpora HiDPI není binární věc, ale má několik rovin. Tou nejprimitivnější metodou, jak se poprat s vysokou hustotou pixelů, je škálování písma. To zvládne prakticky každé desktopové prostředí a grafický framework. Velikost mnoha elementů v uživatelském rozhraní se nastavuje podle písma a zvětšení písma, tak může do určité míry pomoci. Má ale daleko k ideálu. Velikost některých prvků (např. ikony) se podle písma nenastavuje a taky velikost písma se nastavuje globálně, což má hodně tragické výsledky, když vedle HiDPI monitoru používáte ještě klasický (to je i můj případ).

Abyste mohli plnohodnotně škálovat, potřebujete moderní grafický framework, což jsou v případě Linuxu GTK+ 3 a Qt 5. Ty už dokážou škálovat plnohodnotně celé uživatelské rozhraní a to už několik let. I u nich ale vyvstává problém a to s monitory, které nejsou tak úplně HiDPI.

Za HiDPI monitor se považuje takový, který má více než dvojnásobné DPI než standardní monitor. U GTK+ 3 je tato hranice stanovená na 192 DPI. Na monitorech s vyšším DPI začne GTK+ 3 automaticky škálovat na 200 % a všechno je velikostně podobné jako na monitorech se standardním DPI. Problém je v tom, že dneska se prodává řada monitorů, které jsou někde mezi. Jsou to téměř všechny 4K monitory, které se typicky prodávají ve velikosti 27-28″. Jejich DPI je někde kolem 165, což je příliš mnoho na škálování 100 % a příliš malé na škálování 200 %.

Qt a GTK+ tento problém řeší rozdílnými způsoby. Qt má podporu pro neceločíselné škálování (tedy např. 150 %, neboli 1,5x) zabudovanou přímo v sobě. Naše zkušenosti s tímto řešením jsou zatím dost rozpačité. Vývojáři GNOME a GTK+ došli k závěru, že podporovat neceločíselné škálování v grafickém frameworku je komplikované, a rozhodli se, že GTK+ bude i nadále škálovat po celých číslech a doškálovávání na ideální velikost bude provádět kompositor Mutter. Ten by totiž měl mít nejlepší přehled o jednotlivých monitorech, jejich velikosti, rozlišení a nastavení.

Pokud tedy máte 28 palcový 4K monitor, který má 165 DPI a ideální škálování by pro něj bylo 150 %, GTK+ škáluje rozhraní aplikací na 200 % a Mutter potom vezme obsah okna a zmenší jej o čtvrtinu na 150 %. Funguje to pěkně u moderního frameworku, který umí škálovat. Problém je u aplikací, které škálování nepodporují. Pro Mutter je obsah okna bitmapa. Aplikace, které neškálují, tak roztáhne o polovinu na 150 %, případně u opravdových HiDPI monitorů i na 200 % a výsledkem je rozmazaný obsah okna, což je pravý opak toho, čeho chtěli uživatelé nákupem HiDPI monitoru dosáhnout.

Podpora neceločíselného škálování se jako experimentální nachází v GNOME 3.26 a najdete ji ve Fedora Workstation 27. Pracovaly na ní společně Red Hat a Canonical. Musíte ji však zapnout v dconfu pod /org/gnome/mutter/experimental-features a musíte také používat GNOME na Waylandu. Bohužel dle mého názoru přináší pro majitele opravdových HiDPI monitorů docela výraznou regresi. Jak popisuji v předchozím odstavci, pokud aplikace škálování nepodporuje, Mutter škáluje bitmapu jejího okna, což má za následek rozmazané rozhraní. Bohužel za neschopné škálování se považují všechny aplikace, které nepoužívají moderní framework a nebeží nativně na Waylandu. A v tom je právě ta regrese.

Některé aplikace totiž mají implementované vlastní škálování. Příkladem takových aplikací jsou Firefox, Chromium/Chrome, Telegram. Ty sice neběží nativně na Waylandu a nepoužívají ke škálování Qt nebo GTK, ale pokud detekují, že běží na monitoru s dostatečně velkým DPI, samy upraví své rozhraní. Na HiDPI monitorech tak fungují bez problémů. Problém mají jen s automatickým přeškálováváním, když jejich okno přetahujete z HiDPI monitoru na standardní a naopak. To je totiž další úroveň podpory HiDPI. Váš desktop a aplikace by si měly poradit s různými monitory o různé hustotě pixelů a automaticky přeškálovávat, pokud mezi nimi okna přetahujete.

To dnes pěkně funguje s GTK+ 3 a GNOME na Waylandu. Na X11 různé škálování na různých monitorech nefunguje a asi ani nikdy nebude. Podle vývojářů by to bylo sice o cosi složitější než na Waylandu, ale realizovatelné. Bylo by to ale hodně práce navíc, což si nemůžou dovolit. A vzhledem k tomu, že Wayland je budoucnost, přirozeně padla volba na něj.

Po vyzkoušení experimentální podpory neceločíselného škálování v GNOME, jsem jej zase vypnul a vrátil se k předchozímu řešení, které umí škálovat pouze na 200 %. Pro DPI přes 200 je to ale ideální hodnota a škálují mi také Firefox, Chrome a Telegram, které se nesnaží Mutter přeškálovat sám, ale nechává jim volné pole působnosti využít jejich vlastní škálování. Ano, tyto aplikace se mi nepřeškálují automaticky při přesunutí na druhý monitor, ale mám je vždy puštěné na primárním monitoru, takže mi to ani tak nevadí. Docela použitelné jsou i aplikace postavené na GTK+ 2. Neumí sice škálovat, ale alespoň se jim škáluje písmo, takže většina UI má odpovídající velikost. Zcela neškálují pouze aplikace, které nemají vlastní škálování a vše si bundlují, v mém případě to je jenom Spotify.

Bohužel v GNOME 3.26 se momentálně nachází chyba v GNOME Shellu. Ten totiž neškáluje podle primárního monitoru, což je v mém případě ten externí se standardním DPI, ale podle zabudovaného HiDPI monitoru, takže na primárním, kde se nachází veškeré UI Shellu, je vše příliš velké. Ještě nevyšla ani beta Fedory 27, takže jsem ochotný takové chyby akceptovat, ale doufám, že se to do finální verze opraví, protože momentálně mě to donutilo se vzdát používání dvou monitorů.

Pokud máte monitor, který má DPI někde mezi 125 a 192, doporučuji neceločíselné škálování vyzkoušet. Celočíselné škálování vám asi nefungovalo příliš dobře a mohlo by to pomoct. Navíc Mutter nemusí okna neškálujících aplikací roztahovat tak moc, jako na velmi jemných monitorech, takže by ani nemusela být tak rozmazaná.

Do budoucna je na aplikacích, aby se přizpůsobily. Firefox už GTK+ 3 používá a experimentálně běží i na Waylandu. Chrome na GTK+ 3 pomalu přechází a v plánu je i podpora Waylandu. Potom budou vyřešené dvě nejdůležitější desktopové aplikace. Ostatně podobné problémy řeší i Windows. Systém a moderní frameworky můžou HiDPI monitory podporovat dobře, ale vždycky se najdou aplikace, které na to nejsou připravené. Proto i na Windows narazíte na aplikace, které jsou rozmazané. Jejich okna jsou totiž také roztažená.

Musím ale říct, že HiDPI monitor za to opravdu stojí. Na vyšší rozlišení se velmi rychle zvyká a vše je perfektně ostré. Věci jako subpixelové vykreslování to posílá do propadliště dějin.

Reklamy
O HiDPI v Linuxu

One thought on “O HiDPI v Linuxu

  1. Lukáš Polívka napsal:

    Na podporu ve Fedoře se těším, i když to teda nezní pořád nijak ideálně.

    Na Windows 10 mi dnes dělá problémy snad jen Chrome a to jen pokud připojím externí projektor, kdy se mi mění rozlišení / škálování. Chrome ale stačí minimalizovat a zase maximalizovat a škálování je OK. Ve Windows 8/8.1 jsem musel po změně škálování půlku aplikací restartovat, aby se zobrazily správně.
    Většinu času mám integrovaný i externí displej už HiDPI (2 × 2560 × 1440).
    Občas ještě používám externí projektor (1920 × 1080), i tam jsem si teda zvyknul nastavovat na prezentace/školení škálování na 150 nebo 200 %, aby to i lidi v zadních řadách přečetli. 🙂 (Na to je to škálování super, zvětšování fontů způsobovalo spíš problémy.)

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit / Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit / Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit / Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit / Změnit )

Připojování k %s