Bez do toho hned, ja mam 4K monitor od Philipsu 40" uz 3 roky a nemuzu si stezovat, jasne byly vyjimky, napr. a nejenom pgmodeler, nebo pgadmin, dalsi tools postavene na Java(Oxygen XML, Netbeans...), tak jsem mel pripojeny vzdy jeste jeden monitor s nizsim rozlisenim, dnes uz ho nepotrebuju, aplikace, ktere pouzivam uz migrovaly.
Behem te doby vysla od Philipsu (jako stoji bratru asi 12,000 bez DPH) nova verze 43". Tak mam v praci ten puvodni a doma mam dva vedle sebe, jeden horizontalne, vedle nej vertikalne, jak potrebuju.
Kdyz nekdo ten monitor videl pred tema trema rokama i ted v novy praci, tak padaly otazky jako jestli se na tom dobre pracuje.... Ja uz mensi nechci v zadnym pripade :-)
nj, mas pravdu, asi unava materialu dnes uz...
Jen doplnim, ze HiDPI v mem pripade je vzdy pracovni laptop Dell XPS 15 4K + 40" 4K monitor, prvni generaci tech laptopu jsem mel taky ~3-4 roky zpet, a celkove kdyz mela aplikace problem na laptopu mela i na 4K 40" (non HiDPI), coz pricitam obecne skalovani. Nektere open source aplikace jsem pomahal testovat na skalovatelnost a kdyz uz jsme se dostali pres ramecky a fonty obecne (vsechny postavene nad Qt5.*), tak je zde jeste dalsi celkem pracny proces, pripravit high-resolution ikony :-)
Cau, mohol by si prosim ta odfotit svoj setup? Ja mam momentalne 2x 40 na sirku vedla seba a kedze mam hrany displeja v strede stola, byvam casto krat nejakym sposobom vytoceny a celkom ma z toho boli chrbat a krk.
To tvoje riesenie sa mi paci, no neviem si prilis dobre predstavit ako by som s tym bol schopny pracovat.
Napis mi na ladislav.jech (at) seznam.cz, jsem ted v zahranici, odfotim az se vratim.
Jinak jsem ted shanel drzaky na ty monitory a moc jsem nepochodil, chtel jsem kloubove pro dva, pro 3 a pro 6 (to je pro monitoring room), ptal jsem se na:
http://www.televiznidrzaky.cz/
Jako nejak by mi to dokazali slepit, ale ze zatim tyhle dvoj a vice ramenne vyrabeji jenom do circa 32" max.
Tipnu si, že to má dva metry od sebe, nebo se u toho točí na židli.
Osobně mám jenom jeden 1600p monitor, původně 30" a nyní širokoúhlý 38", a je to hraniční. Třetinu obrazovky používám pouze na odkládání oken a kdybych na ty okraje měla koukat pořád, vadilo by mi to. Už tak někdy cítím krk.
Mam v kanceláři 27' monitor s Windows 7 se zvětšeným písmem, abych něvo přečetl a občas je sranda u toho sedět a něco dělat, protože ty aplikace často některý prvky nedokážou vůbec zobrazit a to nemluvim, když se na svůj desktop připojim ze svého 12' laptopu :) Řikal jsem si jak je na tom v tomhle směru ťreba takový gnome desktop.
Myslim ze KDE je na tom daleko lepsie jak widle, pri beznom pouzivani som ziadne problemi nezaznamenal. Naopak vo Windowsoch som mal problem napr s Chromom, v okne na celu obrazovku mi obcas uskakoval horny panel, nektore aplikacie mali rozmazane pismo.. samostatnu kapitolu tvori macOS, tam to funguje na jednotku
Ahoj, ono se take chce zamyslert nad tim, jaky monitor a na co ho porizujete. U notebooku je to predem dane, o tom netreba asi diskutovat, ale u stolniho 4K monitoru to uz tak jasne neni. Delam grafiku a mam 43" a zvetsovat nic nepotrebuji a bylo by to i kontraproduktivni - potrebuji toho videt co nejvic najednou a "hledat" mouchy na urovni pixelu. Na kancelarinu si 4K monitor asi neporidite (teda aspon zatim....), nicmene mam kamarada co vidi jen na jedno oko a jeste blbe a pokud vim tak tyhle blbosti pouziva a od sedmicek nema problem.
Mám 32" 4k monitor, a situace v oblasti škálování je poměrně dost tristní. Windows se prakticky nedají použít, a v Linuxu je pro co nejlepší podporu nutné jít cestou KDE Plasma. Na KDE jedu už delší dobu, a je pravda, že se na to parádně zvyká, a někteří Windows kolegové se diví jak to že to na tom monitoru tak hezky vypadá.
Spousta software ale má ještě dost mezery, a kámen úrazu jsou některé programy, které si myslí, že to škálování dokážou líp. Typicky Firefox na Windows na 4k, to je hotové utrpení.
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
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 .
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
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í.
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.
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.
Pracuji na 24" obrazovce s WQHD (2560x1440) ze vzdalenosti asi 1 metr (natazena paze + 20 cm?) a nemam problem s velikosti prvku nativniho dpi na linuxe (xfce) i windows.
Bohuzel dle clanku zjistuju ze v roce 2017 vyvojarum DE stale nedoslo, ze maji prostredi delat ve vektorech (grafiku i fonty).
U windows me to neprekvapuje, tam proste zoomuji bitmapu kam az to jde a pro kazde "dpi" (zoom) maji jinou bitmapu - proto cast prostredi vypada ostre a zbytek jedouci na MS-like pristupu je rozostren/rozmazan a deformovan protoze vyvojar pouziva jen jednu zakladni bitmapu pro vsechny rezimy.
U linuxu me to prekvapuje, zejmena u velkych projektu. Fonty si myslim se pouzivaji vektorove v DE i aplikacich dlouho (alespon v tech co pouzivam), ale co se tyka grafickych prvku - to opravdu stale vyuzivaji bitmapu namisto vektoru? Vzdyt grafika prostredi i aplikaci neobsahuje zadne tvary a prvky se kterymi by mela vektorova grafika nejakej problem...
Tak kde je sakra teda problem? Zvlast kdyz se pracuje na waylandu o nuly (zelene louky)!
Muzou se inspirovat u chovani html, kdy se da cela webova stranka/aplikace udelat vektorova a prizpusobi se jakemukoliv displeji.
Pak si clovek rika ze je opravdu skoda ze neprorazil pristup FirefoxOS.
Nemam problem prispet projektum financne na vyvoj (v ramci mych moznosti, nejsem zbohatlik), ale musi to byt vyvoj smysluplny.
O tom prečo sa nepoužívajú vektorové ikonky je pekne rozpísané v tomto článku:
http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html
Ale moderní frameworky škálují pěkně. Napište aplikaci v GTK+ 3, které tu už je 6 let, a nemáte problém. Jenže uživatelé požívají desktopové aplikace, které jsou klidně 15 let staré a od té doby se výrazně nezměnily. V té době se s něčím jako HiDPI monitory vůbec nepočítalo. Žádný systém nedonutí takovou aplikaci, aby vykreslovala obsah svého okna škálovatelně.
Bohuzel dle clanku zjistuju ze v roce 2017 vyvojarum DE stale nedoslo, ze maji prostredi delat ve vektorech (grafiku i fonty).
V roce 2017 jim to samozřejmě dávno došlo. GTK 3.x je komplet vektorové, stejně jako Qt 5, a jak je v článku řečeno, u aplikací, které používají tyhle frameworky, to "prostě funguje" (alespoň na Waylandu). Problémy jsou u aplikací se starými knihovnami kde se skutečně ještě používaly bitmapy a pixelový systém souřadnic. Tyhle frameworky vznikly kdysi dávno, ale aplikace na nich založené se stále používají a ještě dlouhou dobu se používat budou.
Proč? Ve výsledku to je jenom o přesném vyhodnocení, jaké má daný monitor DPI. To IMHO nejlépe ví compositor, který se o display management stará. Samozřejmě, pokud si grafický framework dokáže onu informaci zjistit stejně spolehlivě, tak proč ne, ale třeba v případě Qt to v našem testování tak vždycky nebylo.
Protoze kdyz se skalovani provadi dvakrat, tak spis vypada ze se to rozsype.
Neboli proc teda nepracovat na tom, aby graf. framework dokazal spolehlive zjistit onu informaci? Tim by odpadlo dvojite skalovani, navic to druhe jen s bitmapou ktere to rozmaze.
Jestli neni vhodne mit vsechno vektorove (ikonky jsou lepsi bitmapove, protoze potrebuji pixelovou optimalizaci), tak mi pripada ze informaci o DPI uz teda musi mit program (graf. framework), a pokud ji ma az kompozitor, tak je to blbe.
Co teda brani tomu, aby aby si graf. framework zjistil tu informaci spolehlive?
Ano, ale kolik těch frameworků máte? GTK, Qt, WxWidgets, Skia, EFL, Swing,... Předpokládat, že všechny budou zvládat neceločíselné škálování, je dost naivní. Že v budoucnu zvládnou alespoň celočíselné škálování, je přece jenom pravděpodobnější a na neceločíselné škálování se použije společný mechanismus.
Sice to uplne nesouvisi s tematem clanku, ale i tak se zeptam.
Uvazuji uz delsi dobu o novem notebooku a Dell XPS 13 by se mi libil.
Chapu spravne, ze k nemu neexistuje klasicka dokovaci stanice, ale je nutne vyuzit USB-C?
Je mozne notebook po USB-C i napajet? Bylo by o nicem mit dokovaci stanici, ale pripojovat 2 kabely do notebooku.
Da se k Dell XPS 13 sehnat klavesnice s trackpointem? Ja ji nenasel.
Klasická dockovací stanice, do které byste notebook zacvakl neexistuje, těžko se to dělá s hliníkovým unibody a celkově se od toho mezi výrobci upouští ve prospěch připojování USB-C kabelu.
USB-C/Thunderbolt má tu výhodu, že je standardizovaný napříč výrobci, takže můžete klidně používat něco noname z Číny, nebo dock daného výrobce nebo klidně jiného. V práci používám Dell TB16, ale ten je docela drahý, Dell třeba nabízí i menší za cca 1500 Kč (ethernet, VGA, HDMI, USB). Zkoušel jsem XPS 13 i s dockem od Kensingtonu nebo Lenova a fungovalo to bez problémů. I TB16 na noteboocích od Lenova. Jen Macbooky se nechytali, hlásilo nám to necertifikované zařízení a hotovo.
Klávesnice s trackpointem AFAIK Dell nedělá, minimálně XPS modely je nemají.
A umožní vám to nastavit různé škálování na různým monitorech? Já totiž používám dva monitory s výrazně rozdílným DPI, takže pokud to neumí různé škálování na různých monitorech, je to pro mě nepoužitelné.
A taky mám tušení, že to bude mít vliv jen na velikost písma, Qt ani GTK+ podle toho plnohodnotně škálovat nebudou.
Ocenil bych jinou věc, a to je něco jako škálování jednotlivých oken. Něco jako lupa v kompozitním správci oken, ale lépe vyladěné.
Využil bych to u starých her, které jsou dělané natvrdo pro 640*480 nebo 800*600.
Zkoušel jsem to právě přes tu lupu, ale negativně se to podepsalo na výkonu a hlavně se kurzor choval dost divně.
Pak jsem zkoušel vyhrazený X server na jedné obrazovce (mám jich víc), to samozřejmě fungovalo, ale mělo to zase jiné mouchy.
Jinak škálování desktopu nepotřebuji. Radši dám přednost obrazovce se 140-170 dpi, na kterou se mi toho víc vejde.
V prispevkoch sa objavilo viacero pochybnosti ci nepresnosti ohladom zoomovacky v macOS. Siel som teda odskusat aplikacie nativne aj nenativne ako sa popasuju so zoomom: nativna macos (iTunes), electron (Atom), wine (Total Commander), Xwin (Inkscape), java (JaVaWa GMTK). Vsetko v macOS 10.13 High Sierra. MBP pripojeny cez DP kabel ku 4K monitoru, oba zapnute. Kazdy monitor moze bezat na inom rozliseni a inom zoome (len na hidpi monitoroch sa zobrazi "scaled" = zoom volba). Presun okna medzi monitormi nerobi ziaden problem aj ked idu v inych nastaveniach rozlisenia ci zoomu.
MacbookPro 2015 13" interny displej 2560x1600
ponukane zoomy:
2.50x (like 1024x640)
2.00x (like 1280x800)
1.77x (like 1440x900)
1.52x (like 1680x1050)
externy Samsung U24E850 23.5" 3840x2160@60Hz (4k)
ponukane zoomy:
2.55x (like 1504x846)
2.00x (like 1920x1080)
1.66x (like 2304x1296)
1.50x (like 2560x1440)
1.27x (like 3008x1692)
Vysledky:
Samsung 4K:
===========
Zoom 2.55x: nativne & electron perfektne, xwin 90%, java 85% (viditelny aliasing), wine zubate a rozmazane dost zle
Zoom 2.00x: nativne & electron perfektne, java & xwin trochu menej ostre, wine viditelny antialias
Zoom 1.66x - 1.5x: uz je problem rozoznat nativnu, xwin a java apku, vyzeraju skvele. Wine este vidno trochu maznute.
Zoom 1.27x: vsetko vyzera dobre, aj wine
MBP Retina:
===========
Ma lepsie PPI a tak rozdiely su este menej viditelne, zjavne rozdiely medzi apkami vidno iba pri 2.5x a od 1.77x nizsie ich uz musite fakt hladat, dokonca aj wine je OK.
Co je dolezite poznamenat VSETKY testovane aplikacie pri zmene zoomu skaluju v poriadku. Pripadny antialias vobec neprekaza a da sa s tym v pohode pracovat. Ziadne artefakty, nesumerna velkost ikoniek ci pisma, vsetko skaluje a funguje ako ma. Navyse tento test bol extrem, lebo 99% uzivatelov macOS pouziva iba nativne apky a tam je zoomovacka dokonala.
Skusal som este zmenu rozlisenia pomocou EasyRes utilitky (zadarmo v AppStore) ta vam umozni este ovela viac rozliseni, ale uz hardwarovo - zoom nerobi operacny system ale priamo monitor.
Vida kdyz se chce tak to jde. Chystal jsem se koupit Lenovo Yoga 910 a provozovat tam Fedoru s Waylandem ale jak na to tak koukam nebude to lehky. Normalne zvazuji, jestli radeji nekoupit Macbook Pro, cenove je to +/- stejny. Temer vsechny aplikace co pouzivam jsou i pro macOS a neriskoval bych HiDPI problemy.
Díky za přehled. Vychází mi z toho, že lepší podpora v macOS je víceméně celá o tom, že je ta platforma unifikovanější a téměř všechny aplikace používají nativní framework a pokud možno v nejnovějších verzích. Pokud člověk používá jenom GTK3 aplikace, tak je ta podpora v Linuxu také víceméně bezchybná. Nicméně aplikací pro Linux, které jsou napsané v něčem jiném a ještě v něčem, co HiDPI moc neumí, je asi výrazně větší procento než na Macu.
Nasel jsem zajimavy trik jak rychle zjistit jestli apka bezi ve waylandu nativne nebo pres Xwayland - staci spustit xeyes a nabehnout mysi nad okno aplikace. Az se ocicka koukaji na vas kurzor je to spatny a mate pod nim zastaralou X starozitnost. Az se ocicka nehybou tak jste za vodou a apka wayland umi :-)