Microsoft „prawie” uporał się z problemem, jaki trapi Windows od lat. Chodzi o skalowanie aplikacji…

Interfejs Windowsa wykorzystywany w systemie operacyjnym i aplikacjach na niego nie był projektowany z myślą o wyświetlaczach o bardzo dużej gęstości pikseli i ciągłym przełączaniu się pomiędzy nimi. Dlatego gdy te zaczęły się pojawiać na rynku, a komputery stały się prawdziwie mobilne traktując monitory jak wymienne akcesoria, problem zaczęto rozwiązywać w sposób przypominający zalepianie dziur przeżutą gumą do żucia. Dopiero w Windows 8.1 firma Microsoft poradziła sobie z poprawnym przenoszeniem okien pomiędzy wyświetlaczami o różnej gęstości pikseli, a i tak ten konkretny mechanizm musiał być jeszcze dopracowany w Windows 10.

Warto zaznaczyć, że problem ten dotyczy wyłącznie tak zwanych aplikacji pulpitowych, określanych też umownie aplikacjami Win32. Aplikacje typu Modern oraz typu UWP nie mają najmniejszego problemu z dynamicznym dopasowywaniem się do aktualnie wykorzystywanego wyświetlacza. Problem w tym, że aplikacje pulpitowe są nadal chętnie wykorzystywane i tak pozostanie w przewidywalnej przyszłości.

Dopóki pracujesz na swoim ultrabooku z pięknym wyświetlaczem choćby i 8K, nie będziesz miał najmniejszego problemu. Spróbuj jednak podłączyć do niego monitor o zupełnie innych parametrach i zaczną się schody. Powiększone lub pomniejszone ikony, nienaturalne proporcje kontrolek w programach, dziwnie niepasująca do reszty czcionka, i tak dalej. Problem rozwiązuje wylogowanie i zalogowanie ponowne na konto, wtedy nagle wszystko na obu wyświetlaczach wyświetla się poprawnie. Ale wystarczy że odłączysz monitor i… dla odmiany narobisz bałaganu na natywnym wyświetlaczu, wymuszając konieczność ponownego zalogowania. Lub zaciśnięcia zębów z irytacji i pracowaniu dalej na tym estetycznym potworku.

Żaden znany mi unixowy system nie posiada takich problemów, a występują one tylko na Win32 (wśród popularnych platform) z uwagi na… krótkowzroczność. Win32 i aplikacje nań pisane najzwyczajniej w świecie nie były projektowane z myślą o wysokiej gęstości pikseli czy jej dynamiczną zmianą. Aplikacja tego typu „nie wie”, że właśnie tryb wyświetlania się zmienił. I „nie rozumie”, że już nie jest wyświetlana na 12-calowym wyświetlaczu 2K, a na 27-calowym Full HD (dla przykładu). Działa na dotychczasowych parametrach, jakie „zebrała” przy uruchomieniu. Przy czym problem ten nie wystąpi we wszystkich aplikacjach Win32. Ich twórcy mogą w nich implementować mechanizmy wykrywające aktualne parametry wyświetlacza. Muszą to jednak zrobić sami, system operacyjny automatycznie tego nie robi. Jak nietrudno się domyślić, znaczna część aplikacji nadal nie ma takiego mechanizmu, a spora część się go nie doczeka nigdy.

Problem z „niesfornymi” aplikacjami i problemami z ich skalowaniem jest dwojaki. Po pierwsze, sam system operacyjny nie zapewniał wszystkich informacji niezbędnych do przeskalowania jej do nowych warunków, a po drugie znaczna część aplikacji w ogóle nie przewiduje przyjęcia informacji o nowej przestrzeni roboczej, trzymając się uparcie tego, co zarejestrowała podczas uruchomienia.

Pierwszy problem został rozwiązany przez przejęcie tego, czego aplikacja nie rysuje bezpośrednio (pasek tytułu, systemowe menu, paski przewijania, i tak dalej) przez system operacyjny, choć nie jest to wymuszane na każdej aplikacji (by niczego nie popsuć). Jej twórca musi przełączyć moduł rysowania na tryb EnableNonClientDpiScaling, by system zajął się poprawnym skalowaniem kontrolek systemowych aplikacji.

Kolejnym usprawnieniem jest rozbudowanie poprzez uproszczenie (sic!) skalowania samego interfejsu. Do tej pory aplikacje deklarowały w systemie czy są „świadome” jak się skalować, i czy są „świadome” tego że muszą dynamicznie przełączać skalowanie gdy są przenoszone pomiędzy wyświetlaczami. Jeżeli czegoś nie zadeklarowały, system sam zajmował się automatycznym skalowaniem, a ów automat, czego dowodzą problemy obecne w Windows po dziś dzień, jest daleki od doskonałości.

Ten model sprawdzał się jednak w prostych aplikacjach. Jednak te o rozbudowanym interfejsie, często polegającym na wyświetlaniu dodatkowych okien, to już zupełnie inna kwestia. Twórca aplikacji, do tej pory, musiał przygotowywać wiele różnych wersji i kombinacji tego samego wielooknowego interfejsu lub… ignorować problem i słusznie zwalić to na niedoskonałość Windows. Jednak wraz z nowym API o nazwie SetThreadDpiAwarenessContext określanie wartości skalowania dla poszczególnych podokien już twórcę nie obchodzi. Jeżeli główna aplikacja wie jak skalować swój interfejs, to również wszystkie jej podokna będą to wiedziały.

Aplikacjami pokazowymi dla nowej metody skalowania będzie, a jakże, pulpitowa wersja Microsoft Office. Jedna z przyszłych aktualizacji dla tego zestawu aplikacji wprowadzi obsługę wszystkich nowych API związanych z nowymi metodami skalowania. Usprawnione zostanie o powyższe zmiany też przy okazji środowisko WPF.

A Microsoft o tym wie i pisze o tym na swoim blogu, będącym źródłem tej notki. Skalowanie ikon nadal nie działa poprawnie przy wykorzystaniu wielu monitorów, tak samo jak skalowanie systemowych kontrolek Common Controls (i, co z tego wynika, również WinForms). Nadal jedynym rozwiązaniem na poprawne skalowanie wszystkiego na ekranie wymaga wylogowania się przez użytkownika i zalogowania na nowo.

Co ciekawe, Microsoft nie obiecuje, że ten problem kiedykolwiek zostanie rozwiązany w pełni, nazywając go „trudnym zagadnieniem informatycznym”. Możliwe, że środowisko Win32 nie jest w ogóle w pełni naprawialne. Co stanowi pewien problem biorąc pod uwagę, że perfekcyjnie skalujące się aplikacje UWP nadal nie cieszą się szczególnym powodzeniem zarówno u programistów, jak i użytkowników.