Akurat to nebol fractional scaling, ale specifikacia DPI pre displej (nie screen!). Bolo mozne mat viacero screenov s rovnakym dpi v ramci jedneho displeja, alebo viacero displejov s jednym screenom, ale v druhom pripade nebolo mozne presuvat okna z jedneho na druhy - aplikacia musela na jednom displeji okno zrusit a na druhom vytvorit. Toto zvladal akurat XEmacs, nic ine. Co sa tyka samotneho dpi, aplikacie nacitali globalne nastavenie pri starte, pouzivali ho po zvysok session a skalovali iba velkost fontov, ale nie ostatnych assetov, obzvlast nie rastrovych. Vyzeralo to dost zle a presne toto hidpi riesi.
No a ze sa pracuje na whiteliste pre specificke aplikacie? Zabity cas, riesenie pre jednu aplikaciu, ale ked to niekoho bavi, nech sa hra. Google mohol radsej zapracovat na podpore Waylandu v Chrome... Ostatne stare X11 aplikacie s tym fungovat aj tak nebudu, z dovodu, ktory som spomenul vyssie.
Vo Windows situacia je podobna - 99% aplikacii pri pouziti s large fonts (co je ekvivalent X11 dpi) je rozbitych. Preto Windows 8/10 prisli s novymi API pre hidpi.
MacOS zase pre zmenu povie vsetkym aplikaciam ze bezia v hidpi (ak je aspon jeden pripojeny displej hidpi) a skaluje to smerom dole v displej serveri. Vysledky to dava vacsinou uspokojive, okrem niektorych velkosti, ako napr. 125%. Preto tato velkost, popularna v PC svete (fullhd@14"), v MacOS nie je dostupna vobec.