Vlákno názorů k článku HiDPI v Linuxu: podpora se zlepšuje, kazí ji staré aplikace a frameworky od Kylo - No je skvele, ze se tim nekdo vazne...
-
koroptev (neregistrovaný)
jak presne to bezvadne funguje na macosu? nenasel jsem moznost nastavit globalni scaling pro jednotlive displeje (trebas ani ne kvuli dpi ale kvuli mym ocim), musim to resit per aplikaci s ruznym stupnem uspechu; mam z toho dojem, ze to ma jen sutomatiku, ktera na zaklade dpi displeje mozna neco dela; coz na tech displejich mezi "malym" a "velkym" dpi je naprd
-
Kylo (neregistrovaný)
Normalne, System preferences -> Display a na kazdem displeji se ti ukaze extra okno kde si to muzes nastavit zvlast. Nebo nahod utilitku DisableMonitor kde si muzes prepnout na vsechny mozne i nemozne velikosti co tvuj monitor podporuje https://github.com/Eun/DisableMonitor .
-
koroptev (neregistrovaný)
pohledem na https://raw.githubusercontent.com/Eun/DisableMonitor/res/screenshot1.png se nezda ze by DisableMonitor umelo neco jineho nez ze mi umozni zvolit nizsi nez nativni rozliseni, coz neni resenim problemu; pri korektnim reseni bych mel ostre pismo, kdyz zvolim nizsi nez nativni rozliseni, prepocitava ho displej/karta na nativni a macos renderuje to pismo v nizsim, coz je napicu
-
koroptev (neregistrovaný)
tuto nabidku https://www.emacconsulting.com/wp-content/uploads/2015/08/iMac-Display-Pref.jpg to pravdepodobne nabidne jen pokud to detekuje pripojeny retina displej, nevim, proste za nejakych okolnosti; coz je mi napicu, kdyz mam displej nekde na rozhrani nebo bych proste jen chtel globalne "vetsi obraz"
-
V čem to prosím funguje na macOS lépe? Všechny systémy mají problém se starými aplikacemi, které neškálují. To je ten největší problém, který nelze jednoduše a dostatečně uspokojivě vyřešit.
Jinak Apple si výrazně ulehčil práci tím, že rozlišení na svých počítačích prostě zdvojnásobil, zatímco Windows a Linux se musí potýkat s kdejakým DPI, které se na trhu objeví. -
Kylo (neregistrovaný)
Nemate pravdu. Treba kdyz pripojim externi 4K monitor k macbooku tak si muzu zoomovat 2x, 1.5x, 1.3x u kazdeho rozliseni co je monitorem podporovano (coz napr. u toho 4K je snad 12 rezimu). Samozrejme nejlepsi to je kdyz bezi v 4K. A skaluji uplne vsechny aplikace, nevim co myslite pod pojmem "stara aplikace" snad jeste neco co frcelo na PowerPC? To uz stejne nespustim :-) nativni apky maji resources vesmes ve vektorech nebo alespon bitmapy od 16-512px takze to neni ani kostrbaty ani maznuty. Dokonce nejen nativni ale take javacke, wine nebo Xwindow apky jsou Metalem prizpusobeny (tam je uz mozna najit nejaky aliasing pri 1.3x ale je to o svetelny rok pred Win10 ci KDE).
Nac reci, sednete za maca, pripojte externi 4-5K monitor a zirejte jak se to ma delat.
-
"tam je uz mozna najit nejaky aliasing pri 1.3x ale je to o svetelny rok pred Win10 ci KDE"
Jenže na skutečném HiDPI monitoru (třeba na tom XPS 13) potřebujete škálovat na 2-2,5x a věřte tomu, že tam aliasing, který jde vidět při 1,3x, jde sakra vidět. Bavíte se tu externím 4K monitoru. Ty se většinou pod 27" nedělají, to znamená, že mají DPI 163 a nižší. To nejsou skutečné HiDPI monitory (alespoň dvojnásobek toho standardního - 96). Monitor, na kterém to zkouším já, má DPI 276.
Jestli na Macu většina aplikací používá moderní framework, který pěkně škáluje, tak good for them. Pochybuju ale, že to je případ těch Java, Wine a Xwindow appek, tam to prostě roztahuje jejich bitmapy, jen to na tam externím 4K monitoru nejde tak vidět.
-
Kylo (neregistrovaný)
A neslo by to u tech apek v gtk/qt udelat nejakymi profily? Proste user by jsi stahnul z repozitare (nebo udelal sve) metadata pro konkretni apku/rozliseni/zoom co ma nejaky problem? Treba tu nekdo rikal, ze Chrome jsi jde jinak nez KDE5 apky. Co jsi vzpominam tak napr. u win XP/7 slo pomoci manifest souboru dat hinty pro starsi apky a ty pak najednou pouzivali nativni temy, widgety atd.
-
Něco takového zvažujeme. Firefox a Chrome mají vlastní podporu škálování, takže když se jim řekne, že DPI je třeba 192, tak samy naškálují na 200%. Problém je, že když to samé řekneme jiným aplikacím, tak dostaneme dost rozdílné výsledky. GIMP napsaný v GTK+ 2 naškáluje jenom něco (to, co se řídí velikostí písma), takový Spotify vůbec nic. Pro takové je asi lepší jim říct, že DPI je 96, ony naškálují na 100% a kompozitor jejich framebuffer roztáhne na požadovanou velikost. Výhodou je jsou správné velikosti prvků v UI, nevýhodou neostrost.
Řešením tedy je mít dva různé profily. Jeden pro aplikace, které sice neběží na Waylandu a nepoužívají ke škálování Qt5 nebo GTK3, ale škálovat umí, takovým by se sdělovalo vysoké DPI, a jeden pro aplikace, které škálovat nezvládají. Jim se řekne, že DPI je standardní a o škálování se pokoušet nemají. Problém je, že to nejde zajistit v rámci jedné instance X. To znamená, že bychom museli mít dvě různé instance X a řešit předávání informací nejen mezi Waylandem a X, ale i mezi těmi dvěma instancemi X a to už věci dost výrazně komplikuje. -
Ad Řešením tedy je mít dva různé profily - to prakticky popisujete jak je to udělané ve Windows. V těch je možné pro každý executable nastavit škálování typu:
- Application. Aplikace reaguje na HiDPI pomocí vlastních prostředků, typicky pomocí frameworku (Win32, WPF, WinForms). Správně napsaná aplikace umí změnit rozlišení při přesunu mezi FullHD a 4K monitorem, zobrazit na každém z těch monitorů jedno okno atd. Špatně napsané nebo staré aplikace zobrazí některé nebo všechny prvky v nesprávné velikosti.
- System. Aplikace jede v 96 dpi a systém výsledek přeškáluje. Aplikace je neostrá, ale určitě funguje jak má.
- System (Enhanced). Představte si že aplikace jede v 96 dpi a kreslí do bufferu. Ale také má druhý buffer o cílové velikosti, a kreslení písmen je přesměrované tak, že probíhá rovnou do toho většího bufferu. Písmena jsou pak ostrá, ale neostré zůstávají bitmapy, GDI+ contexty, všechno co jde přes DX, a některé aplikace to celé nemusejí tak úplně rozdýchat.
ČLÁNKY DO MAILU
