Dzisiaj, gdy możemy już zakupić laptop o rozdzielczości nawet 3200x1800 na 14", co daje gęstość 260 pikseli na cal (ppi) i podłączyć do tradycyjnego monitora o gęstości 96ppi pojawia się problem zmiany skalowania w locie przy przejściu obiektu między wyświetlaczami. Chciałbym Wam przybliżyć to zagadnienie w oparciu o materiał nadesłany przez Konrada (dziękuję i pozdrawiam!).
okno na gęstym ekranie
okno na obu ekranach wciąż w skali 2,5x
okno na obu ekranach już w skali 1x
okno na docelowym ekranie w skali 1x
Teraz zdjęcie tego samego fragmentu obiektywem Macro, widać zmarnowane piksele, które mogły by uczynić tekst dokładniejszym.
Za to na ekranie 92 PPI jest dobrze, poniżej zrzut
i zdjęcie makro:
i zdjęcie makro
Szczególnie zdjęcie obiektywem makro wygląda okropnie:
Najpierw jednak namawiam Was na zapoznanie się z tym artykułem, który fantastycznie rozprawia się z tym zagadnieniem od strony technicznej.
Teraz spójrzmy na to z punktu widzenia użytkownika - używa on do pracy dwa ekrany:
- 3200x1800, 14", laptop Fujitsu U904, Sharp IGZO, 262 PPI, główny monitor
- 1920x1080, 24", zewnętrzny monitor podłączony po HDMI, 92 PPI
System operacyjny Windows 8.1 dobrał rozmiar obiektów ekranu automatycznie dla każdego monitora: dla monitora 14" przypisał skalowanie ~250% (duża gęstość, mały ekran), dla większego standardowe ~100%, czyli brak skalowania (mała gęstość, duży ekran). Podana skala jest według oceny "na oko".
Przejdźmy jednak do przemieszania obiektów pomiędzy wyświetlaczami - po przesunięciu aplikacji/okna na monitor o innym PPI obserwujemy dwie możliwe reakcje:
- Zwiększenie lub zmniejszenie rozdzielczości okna tak, by w przybliżeniu miało podobny prawdziwy rozmiar widziany przez użytkownika. Tak działa na szczęście 99% aplikacji.
- Brak reakcji, okno pozostaje w takiej samej rozdzielczości. Tak działa np. Task Manager. Gdy głównym monitorem jest ekran 262 PPI i przejdę na 92 PPI, to okno Task Manager na tym pierwszym wygląda dobrze, a na tym drugim jest ogromne.
Kolejne kroki na tych zdjęciach podczas przenoszenia okna z ekranu 262PPI na 92 PPI, bardzo ciekawe zjawisko.
Opcja ta jest wybawieniem przy tak skrajnie różnej wartości PPI monitorów. Działa dobrze, choć autorzy algorytmu skalowania powinni jeszcze nieco popracować nad dokładnością i jakością obrazu po zmianie rozdzielczości. Na głównym ekranie wszystko zawsze wygląda idealnie, a na tym drugim jest różnie, przy powiększaniu lub zmniejszaniu obraz wydaje się tracić ostrość i dokładność.
Oto wersja filmowa przeskalowania okna:
Konrad zaobserwował dwie grupy rezultatów skalowania okien/aplikacji i czcionek ekranowych podczas pracy na głównym monitorze 262PPI z powiększeniem 250%:
A. Czcionki, ikony, okna, które przy 250% się powiększają, ale nie zwiększają gęstości bazowej obiektów
Przykłady aplikacji typu A: Konsola administracyjna Hyper-V, konsola VMware vSphere Client
B. Czcionki, ikony, okna, które przy 250% się powiększają i jednocześnie wzrasta gęstość bazowa (obiekt jest o wiele dokładniejszy, krawędzie gładkie)
Przykłady aplikacji typu B: MS Word, systemowy Explorator Plików, niemal wszystkie okna systemowe.
Aplikacje Modern/Metro UI zawsze wygląda idealnie,bo bazują na wektorach i interfejs był od początku napisany pod gęste ekrany z możliwością szybkiej zmiany gęstości i rozdzielczości obrazu.
Okna aplikacji typu A wyglądają przyzwoicie, ale nie idealnie na ekranie 14" 3200x1800 250%, tutaj gęstość bazowa obiektów nie zgadza się z PPI ekranu. Na ekranie 24" FullHD 100% wglądają za to idealnie, bo gęstość bazowa jest zgodna z PPI ekranu.
Oto przykład dla konsoli HyperV
Okno na ekranie 262PPI (zrzut z ekranu), obraz mało dokładny, po powiększeniu rozdzielczość czcionek i ikon nie zwiększyła się.
Przykład MS Word na ekranie 262PPI (zrzut), aplikacja wygląda pięknie, wszystkie piksele są wykorzystane
Po przeniesieniu aplikacji na monitor 92 PPI jakość okna zdecydowanie spada, czcionki są rozmyte, nie trafiają w piksele.
Okna aplikacji typu B wyglądają idealnie na ekranie 14" 3200x1800 ze skalowaniem 250%. Gęstość bazowa obiektów została przeskalowana (piksele zwielokrotnione), zrównane z PPI ekranu i wszystkie krawędzie są idealnie gładkie. Na ekranie 24" FullHD 100% wglądają za to przeciętnie.
Przy przenoszeniu tych aplikacji pomiędzy ekranami prawdopodobnie zachodzą następujące operacje: gęstość bazowa ustawiana jest dla gęstego ekranu, a skalowanie na 250%. Kolejno obraz jest zmniejszany 2,5-krotnie do 100% i wyświetlany na ekranie o niskim PPI. Niestety w tym przypadku 24" ekran nie ma dokładnie 2,5x mniejszej gęstości, a jedynie ~1,6x. Zatem wiele punktów wygenerowanego obrazu nie trafi w piksele monitora o niskim PPI i zostanie przybliżona, przez co obiekty już nie będą tak ostre.Trudno powiedzieć jaka kombinacja wyświetlaczy pozwoliłaby na idealne "trafienie" punktami w piksele.
Sprawa wygląda nieco gorzej jeżeli głównym ekranem jest duży monitor o mały PPI, czyli w tym przypadku 24" i 92 PPI. Okna są generowane dla powiększenia 100% i monitora 92 PPI. Po przeniesieniu na 262PPI 14" każde okno ma rozmyte obiekty, a dodatkowe piksele gęstej matrycy nie są wykorzystywane. Co gorsze ikony pulpitu są wyświetlane w 100%, czyli są bardzo malutkie.
Jak widzicie problem jest realny i Microsoft włożył sporo pracy w ich rozwiązanie. Inżynierowie jabłuszka obrali inną drogę niż Apple (więcej tutaj) i postanowili używać stałej rozdzielczości wewnętrznej MacOS i stałych współczynników skalowania do matryc. Środowisko Windows jest bardzo różnorodne, więc potrzebne było bardziej uniwersalne podejście. Sądząc z obserwacji Konrada Windows 8.1 Update 1 pozwala na względnie wygodną eksploatację kilku ekranów o różnej gęstości. Rozwiązanie jest pełne kompromisów, ale jest używalne.
Warto podkreślić, że starsze wersje Windowsów miały bardzo ograniczone możliwości w tym zakresie.
