Vlákno názorů k článku Ubuntu poprvé vydalo data o uživatelích: rozlišení, paměť i způsob přihlašování od Boo - "Displeje s HiDPI a 4K ještě nejsou mezi...
-
Boo (neregistrovaný)
"Displeje s HiDPI a 4K ještě nejsou mezi uživateli příliš rozšířené"
Nebude to spise tim, ze linux a HiDPI si porad moc nerozumi a bez rucniho ladeni to nejde ? Kdyz se zeptam kolegu v kanclu jake monitory za posledni 2 roky kupovali tak na 90% 4K. Ale doma versinou maji win nebo mac. Ale napocital jsem 3 lidi co zvladli 4K i na linuxu a pry je to pouzitelne. -
koroptev (neregistrovaný)
kde ma ui scaling a kdyby v jinych ohledech ktere ho vyrazuji z uvahy nestslo uplne za hovno tak by se dalo rici ze nejen hidpi (vetdi problem viz dale maji displeje co jsou mezi normalem a hidpi coz je vetdina) zvlada
gnome na xorgu zvlada jen 96 dpi nebo dvojnasobek na waylandu umi i necelociselny scaling
vsechna ostatni relevsntni (tim vylucuji picoviny jako enlightenment apod) si neumi s faktem ze dnesni displeje nemaji 96 dpi nijak poradit u vsech bezne pouzivsnych toolkitu lze jen zvetsit pismo ale graficke elementy ui zustanou tak jak byly navrzeny pro 96 dpi
ve zkratce - pokud ma clovek presne 4k, je na tom relativne lip, pokud ma cokoli jineho, je v pici, protoze ti curaci, co to programuji, stale jeste ignoruji fakt, ze ruzne displeje maji ruzne dpi; naprosta vetsina tech sracek je delana tak, aby vypadala ok na necem jako 24" nebo 27" ve fullhd a vic ty curaky nezajima
-
Y (neregistrovaný)
Jedná s velkých výhod GUI v Linuxu je že tu jsou v podstatě dvě hlavní skupiny. GNOME a KDE neboli Gtk+ a Qt. A když si někdo zvolí prostředí s Gtk+, zřejmě až na pár výjimek bude používat aplikace v Gtk+. A s Qt to samé. Takže když to máme vše v jednom frameworku, tak se to bude lépe škálovat a ne jako ve Windows kdy je něco v WinForms, WPF nebo MetroUI. A také Win32. Tam je milion najednou používaných frameworků.
-
medzernikStříbrný podporovatelTo je pravda, ale jediny desktop kde vypada cizi toolkit dobre je Plasma KDE 5. Tam vypada GTK aplikace stejne jako nativni. GNOME ma velky problem s dizajnem Qt aplikaci bohuzel.
Ve Windows to vypada vsetcko stejne.
Navic v GTK prostredi kde se nepouziva zadna KDE aplikace to pri instalaci natahaha cele KDE a vsechno s tim skoro.
Pointa je, ze je o dost lepsi zustat na jednom toolkitu a ten druhy ignorovat
-
V distribucích, které toto řeší, to problém není: https://eischmann.wordpress.com/2017/02/10/dark-adwaita-and-highcontrast-themes-for-qt/ ;-)
-
Ondra Satai NekolaZlatý podporovatelTo je pro mobily.
"Retina" je to podle Apple v okamziku, kdy nejde (pri bezne vzdalenosti oka) rozeznat dva pixely. (Coz mimochodem stale jeste neznamena dostatecne rozliseni, aby nesly rozeznat jine zmeny obrazu.)
-
ja (neregistrovaný)
Zdroj: vlastna prax.
Ked zoberiem nejaky mac (napr. Macbook Pro, ktory ma pri 13" rozlisenie 2560x1600, t.j. 227 dpi) a pripojim ho na tento monitor, tak sa k nemu sprava presne ako k internemu displeju: system hodi UI a aplikacie do @2 scalingu. Na to, aby som ho donutil zobrazovat @1, tak musim robit rozlicne prstochmaty v systemovych nastaveniach, aby mi tu moznost vobec dal. Na "low DPI" displejoch to nerobi.
Ako uz Ondra spominal, absolutna hodnota ppi nie je jedinym kriteriom, dalsim je bezna vzdialenost od oci pri pouzivani. Mobil - laptop - externy monitor maju preto rozlicne tresholdy.
-
Ano, HiDPI to moc není, nicméně pro desktopové prostředí a aplikace to je větší oříšek než něco, co má >=192 DPI. Na to totiž stačí celočíselné škálování, které funguje pěkně na všech systémech (Windows, Mac, Linux). U těch 163 DPI je potřeba neceločíselné škálování a to úplně optimálně nefunguje nikde. Apple to vyřešil tím, že prostě zdvojnásobil rozlišení, takže mu stačí škálovat 2x. Funguje to super do té doby, dokud člověk nepřipojí monitor s jiným DPI. Pak musí řešit stejné problémy jako Windows nebo Linux, kterým nezbývá než být připravený na jakékoliv DPI.
-
ja (neregistrovaný)
Oni v Apple vyriesili aj necelociselne skalovanie, ale nekomplikovali tym software. Software stale staluje iba integerom, teda @2 na pocitacoch a @2 a @3 na mobilnych zariadeniach. Finta je v tom, ze rozlisenie framebuffera, do ktoreho software kresli, nemusi byt rovnaka ako je rozlisenie displeja, na ktorom sa zobrazuje.
Vyssie spomenuty MBR pri 2560x1600 je @2 ekvivalentom 1280x800 (co je pomerne tragicke...). Umoznuje ale pouzivatelovi nastavit 2880x1800 alebo 3360x2100 s tym, ze s rozdielom sa ma vysporiadat scaler, ktory ma dnes kazdy hdmi a displayport enkoder.
V X11 je ekvivalentom `xrandr --scale`, ktory urobi presne rovnaky vysledok. Ono to funguje velmi dobre, za podmienky, ze framebuffer ma vyssie rozlisenie ako displej - teda presne naopak, nez to robi Xwayland, ktory skaluje z @1 na >@1, a potom vysledok je rozmazany.
-
Boo (neregistrovaný)
To neni celkem pravda s tim celociselnym. Treba na MBP 13" s Retina (2560x1600) je sice default scaling 2x ale mas uz v zakladnich nastavenich moznost:
1024x640 = 2.5x
1280x800 = 2x (default)
1440x900 = 1.7777x
1680x1050 = 1.5xA kdy pouzijes utilitky tretich stran (napr. EasyRes) tak mas k dispozici desitky dalsich necelociselnych zoomu, vcetne 1x. Minule jsem pripojil ten macbook k 4k projektoru, automaticky navolil ty 4k na monitoru ale z nejakeho duvodu mi na notasu prdlo 1x :-) Nos 5cm od monitoru kym jsem se strefil a nastavil to spravne... O cele to skalovani se stara macOS pres Metal takze uzivatel ani vyvojar nemusi nic resit.
-
Ale to pro mě není žádná novinka. Upscalingem a downscalingem framebufferů si můžu vyčarovat jakou velikost budu chtít i na Linuxu (Mutteru jdou vnutit dokonce i hodnoty pod 1x). Drtivá většina moderních grafických frameworků podporuje celočíselné škálování a neceločíselného se dosahuje právě tím zmenšováním a zvětšováním bitmap framebufferů na úrovni display serveru, které prostě nikdy nebude dávat stejně kvalitní výsledky jako škálování pomocí vektorů ve frameworku.
A taky není pravda, že jako vývojář se nemusím o nic starat a Metal za mě všechno zařídí. Nezařídí. Funguje to stejně jako u Mutteru, prostě to pracuje s framebuffery oken a pokud aplikace neumí škálovat, tak to za ni (kvalitně) neudělá. Stačí se podívat, jak vypadá Inkscape nebo GIMP, které používají GTK2, na Retina displeji. Má to úplně stejné problémy jako v Linuxu a dokud jejich vývojáři neudělají svoji práci a nepřejdou na GTK3, které škálování podporuje, tak to dobré nebude.
-
ja (neregistrovaný)
Vyssie som presne vysvetlil, ako to macOS robi... software vie len integer; **zvysok robi scaler**. Kludne si nastav jedno z tych non-integer rozliseni, potom si urob screenshot celej obrazovky, pozri si jeho rozmery a preskumaj pixely, ktore su v nom. Uvidis, ze je to stale iba integer scaling.
-
Ale XWayland to dělá z jednoho prostého důvodu. Na XWaylandu běží typicky aplikace, které závisí na Xorg, protože používají starší grafický toolkit, který neumí škálovat. Pokud takové aplikaci dám plochu o větším rozlišení na vykreslení obsahu okna, tak se nenaučí z ničeho nic škálovat a vykreslit obsah okna správně na vysokém rozlišení. Výsledkem pak často je rozbité UI, protože prvky, které nastavují velikost podle písma, se zvětší a zbytek zůstane malý. Jde tady tedy o kompromis mezi ostrostí a správnými proporcemi rozhraní aplikace.
Problém byl v tom, že Mutter automaticky předpokládal, že všechny aplikace běžící na Xorg neumí škálovat, což není pravda minimálně pro prohlížeče (Firefox, Chrome...). Těm předhazoval zbytečně malé rozlišení a potom upscaloval jejich framebuffer. Olivier Fourdan ale momentálně do XWaylandu implementuje podporu pro více displejů, kdy jeden se standardním DPI bude pro aplikace, které neumí škálovat, a druhý se skutečným DPI bude pro aplikace, které škálovat umí.
U aplikací, které běží nativně na Waylandu, to funguje stejně jako na macOS. Okna jsou škálovaná na 200 % a Mutter potom jejich framebuffer zmenší na požadovanou finální velikost, třeba 150 %. Ani v tomto případě (stejně jako na jakémkoliv jiném systému včetně macOS) nejsou výsledky úplně dokonalé, ale už dostatečně dobré na to, aby to uživatele netrápilo.
-
ja. (neregistrovaný)
Mal som dojem, ze vo Waylande (tym myslim Mutter) to funguje trocha inak ako v macOS: Wayland to robi per surface pomocou GPU (nastavi kazdy surface ako texturu a potom necha texture sampler, nech to da v spravnej velkosti do skompozitovaneho desktopu?), zatial co macOS to robi per framebuffer pomocou hdmi/dp scalera. Nech vo Waylande nastavim skalovanie ake nastavim, vysledny framebuffer ma vzdy velkost rovnaku ako rozlisenie displeja, zatial co macOS nie. Pristup macOS ma trochu vacsie naroky na VRAM, ale potencionalne menej artefaktov na hranici surfaces, pristup Wayland setri VRAM za cenu vykonu GPU.
Problem Xwaylandu a jeho fixnych 96 dpi bol prave firefox/chrome, potazmo electron aplikacie. Kedze tieto dve su najpouzivanejsie aplikacie na pouzivatelovom desktope, mat ich rozmazane je neakceptovalne. To bol jeden z dovodov, preco aj ja dodnes preferujem X11. Pokial Olivier toto vyriesi, bude to velky krok pre Wayland.
