mva.pl

Tom01 pisze: ↑

15 stycznia 2018, 13:48 - pn

Proszę zwrócić uwagę, że okno panelu sterowania ma Pan prawie na 1/4 ekranu.

Bo tak chwyciłem go kursorem i taki ustawiłem rozmiar (wielkość okien w windows można sobie płynnie zmieniać). Także dalsze Pana obliczenia nie mają sensu.

Jeśli Pan porówna konkretny fragment, to tak samo ma Pan inną ilość pikseli. Ma Pan po prostu większe okna. Co zastanawiające, na moim monitorze 3840x2160px i dużo większej gęstości, renderowanie jest gorsze niż u Pana przy 1920x1200 przy mniejszej gęstości pikseli. Przykład pokazuje ciągle istniejące ograniczenia. Przez całe lata Microsoft nie mógł odejść od powiązania fontów i elementów graficznych z konkretną siatką pikseli. Literka musiała być rysowana w prostokącie określonym konkretną ilością pikseli pion x poziom. Inaczej wyglądało źle. Pamięta Pan jak w czasach przed XP, próba przeskalowania wyglądała masakrycznie? Obecny nasz przykład pokazuje, że skalowanie nadal nie jest uniwersalne, tylko optymalizowane pod konkretne rozdzielczości.


Dla odróżnienia na makówkach wygląda to tak. Przed i po skalowaniu. Wszystko jest rysowane taką samą ilością pikseli, tylko się więcej lub mniej mieści na ekranie.


Proszę zwrócić uwagę, że trzeba się przypatrywać z lupą aby dostrzec różnice w renderowaniu elementów. Pozornie też oba okna są takiej samej wielkości. Wynika to stąd, że założenia skalowania są inne. Nie ma zmiany okien, aranżacji itd, a tylko są wyświetlane mniejsze lub większe. Program nawet "nie wie", że zmieniła się wielkość elementów GUI.

Tom01 pisze: ↑

15 stycznia 2018, 14:32 - pn

Jeśli Pan porówna konkretny fragment, to tak samo ma Pan inną ilość pikseli. Ma Pan po prostu większe okna. Co zastanawiające, na moim monitorze 3840x2160px i dużo większej gęstości, renderowanie jest gorsze niż u Pana przy 1920x1200 przy mniejszej gęstości pikseli.

Windows ma dwa rodzaje skalowania:
1) standardowe - dostępne od razu w oknie ustawienia ekranu, jest to "menu wyboru", gdzie mamy tylko kilka zdefiniowanych powiększeń
2) niestandardowe - wchodzimy do ustawień ekranu, jednak klikamy na "Skalowanie niestandardowe", które znajduje się poniżej "menu wyboru" i tutaj możemy sobie ustawić np. 178%.

Jedna opcja inaczej działa na programy nieskalowalne od drugiej - ale to inny temat.

Ja skorzystałem z drugiej opcji, wpisując 150% i wylogowując się, a najlepiej uruchomić PC ponownie (sugeruję sprawdzić tą drogę).

Pan prawdopodobnie wybrał ze standardowego "menu wyboru" zdefiniowane 150% i nie zrestartował Pan systemu ( uruchom ponownie) - bez ponownego uruchomienia systemu skalowanie standardowe nie działa prawidłowo (widać to jako efekt skalowania rastrowego w górę niektórych okien, co prowadzi do rozmytych elementów systemowych na tych oknach, takich jak np. czcionki).

Nie są to dwa rodzaje skalowania, tylko takie samo z inaczej podawaną skalą powiększenia. Nie zmienia zasady. Ludzie skalowanie w Win traktują jako ostatnią deskę ratunku i wciąż dobierają monitory pod kątem plamki, czyli w efekcie wielkości elementów interfejsu. Nie wiem kiedy i czy w ogóle Microsoft odejdzie od tego założenia. Patrząc po nieskończonej ilości innych wad w Win, należy sądzić, że zamiast zrobić raz a dobrze, Microsoft będzie wiecznie udoskonalał protezę.

Tom01 pisze: ↑

15 stycznia 2018, 14:53 - pn

Nie są to dwa rodzaje skalowania,

Są to dwa różnie działające skalowania na niektóre przestarzałe programy. Jak Pan na jednym skalowaniu ustawi 150% to taki niedorobiony program będzie inaczej wyglądał, niż przy drugiej opcji skalowania do 150%.

Przy poprawnie napisanych programach, faktycznie obie opcje powinny działać identycznie.

Tom01 pisze: ↑

15 stycznia 2018, 14:53 - pn

Ludzie skalowanie w Win traktują jako ostatnią deskę ratunku i wciąż dobierają monitory pod kątem plamki, czyli w efekcie wielkości elementów interfejsu.

Bo nie wiedzą że to działa dobrze w przypadku poprawnie napisanych aplikacji ( no i nie wnikam jak tam przy kilku monitorach, każdy z innym skalowaniem, bo tak się nie bawię)

Tom01 pisze: ↑

15 stycznia 2018, 14:53 - pn

Nie wiem kiedy i czy w ogóle Microsoft odejdzie od tego założenia.

Jak Pan ustawi to jak Panu napisałem, to będzie działało jak na Maku.

Kyle pisze: ↑

15 stycznia 2018, 14:58 - pn

Jak Pan ustawi to jak Panu napisałem, to będzie działało jak na Maku.

Przykro mi, nie ma żadnej różnicy. A co do działania jak na maku, to niech się Pan nie rozpędza. Przepaść.

Kyle pisze: ↑

15 stycznia 2018, 14:58 - pn

Są to dwa różnie działające skalowania na niektóre przestarzałe programy. Jak Pan na jednym skalowaniu ustawi 150% to taki niedorobiony program będzie inaczej wyglądał, niż przy drugiej opcji skalowania do 150%.

Uhm... Spróbuje Pan przemówić do rozumu np najnowszemu Adobe CC? Albo Solidworks?

Powtórzę jeszcze raz: GUI systemu w Windows nie spełnia dobrze swojego podstawowego zadania wynikającego wręcz z nazwy. To ma być interfejs, aplikacja korzysta z niego przez API i tyle. Aplikacji nie powinny obchodzić fikołki systemu. Tak to działa na makówkach, wszystkich możliwych window managerach linuxowych i w ogóle wszystkich graficznych interfejsach użytkownika jakie widziałem. Począwszy od TOS Atari przez masę innych po drodze, po najnowsze. Poza Windows. Tylko tu jest problem. Owszem, można jakoś to poogarniać, znaleźć ustawienia i zestaw oprogramowania przy którym wszystko wygląda akceptowalnie, ale nie o to chodzi aby kombinować.

Tom01 pisze: ↑

15 stycznia 2018, 15:23 - pn

Uhm... Spróbuje Pan przemówić do rozumu np najnowszemu Adobe CC? Albo Solidworks?

To już problem przestarzałych technologicznie najnowszych Adobe CC i Solid works , a nie systemu Windows. Swoją drogą Corel Draw też stosunkowo niedawno dorobili tak, że działa poprawnie.

Tom01 pisze: ↑

15 stycznia 2018, 15:23 - pn

Powtórzę jeszcze raz: GUI systemu w Windows nie spełnia dobrze swojego podstawowego zadania wynikającego wręcz z nazwy. To ma być interfejs, aplikacja korzysta z niego przez API i tyle. Aplikacji nie powinny obchodzić fikołki systemu.

Może wytłumaczę z punktu widzenia programisty. Jak napiszę aplikację w przestarzałym WindowsForms C#, to jest problem ze skalowaniem niemiłosierny i tego przestarzałego diabła powinno się dawno temu zaorać, analogicznie jak zacofany DVI. Jak napiszę w nowoczesnym WPF z XAML też w C#, to wszystko się świetnie skaluje. Po prostu przed pewnymi technologiami jest przyszłość (WPF, DisplayPort) a przed innymi nie ( WindowsForms, DVI, D-sub ). ... a że niektórzy nadal siedzą w przestarzałych technologiach ( WindowsForms ) to mamy i różne z tego powodu problemy.

Kyle pisze: ↑

15 stycznia 2018, 15:56 - pn

To już problem przestarzałych technologicznie najnowszych Adobe CC i Solid works , a nie systemu Windows. Swoją drogą Corel Draw też stosunkowo niedawno dorobili tak, że działa poprawnie.

Te same oprogramowanie Adobe na macOS działa jednak zupełnie normalnie. Co więcej, poddaje się skalowaniu jak trzeba, nie tylko 200% w Windows. Jak na makówkach jest duża zmiana w silniku interfejsu, bodajże w Yosemite było coś dłubane, to jest jasny komunikat jakie wersje są wymagane i po temacie. Utrzymywanie na siłę kompatybilności wstecznej to jest właśnie przestarzałe, skoro lubi Pan to słowo.

Myślę, że nie ma sensu dalej się spierać. Pewnych różnic w założeniach nie da się porównać, bo bez całkowitego przeprojektowania GUI i uporządkowania API, nigdy w życiu to nie będzie dobrze działało. Może co najwyżej, z różną skutecznością, ukrywać defekty. Osobiście mi takie rozwiązanie nie leży i nie widzę powodów dlaczego miałoby być godne obrony. Bubel to bubel, cytując klasyka, nie nazywajmy szamba perfumerią...

Tom01 pisze: ↑

15 stycznia 2018, 16:06 - pn

i uporządkowania API,

o, to to ! O to chodzi.