Jaka jest różnica między ekranem o rozdzielczości 2560 * 1440 z zoomem - 200% a ekranem o rozdzielczości 1280 * 720?

Mam laptopa z natywną rozdzielczością ekranu jako 2560 * 1440. Oznacza to, że ma 2560 pikseli kropek w poziomie i 1440 pikseli kropek w pionie.

Mogę też zmusić system do wyświetlania w postaci ekranu o rozdzielczości 1280 * 720 (co w zasadzie stanowi 1/4 piksela w porównaniu do 2560 * 1440). co zmusza system do użycia 4 natywnych pikseli do wyświetlenia 1 piksela obrazu.

                   .    .
    .       -> 
                   .    .
[2560*1440]      [1280*720]

Podobny efekt, gdy mam rozdzielczość ekranu 2560 * 1440 i powiększenie 200%. tzn. aby wyświetlić każdy piksel obrazu, ekran używa 4 natywnych pikseli.

Nadal widzę różnicę w jasności ekranu między tymi dwoma ustawieniami. Poniżej znajduje się zrzut ekranu dwóch-

ekran o rozdzielczości 2560 * 1440 z powiększeniem 200%

ekran o rozdzielczości 1280 * 720 (bez zoomu)

Czy ktoś może wyjaśnić przyczynę tej różnicy w jasności?

Wygląda na to, że mówisz o „powiększeniu 200%” w niektórych ustawieniach systemu operacyjnego.

Gdy używasz 1280 * 720, wszystko jest renderowane w tej rozdzielczości, a następnie skalowane w górę jako bitmapa (przez monitor). Ostateczny obraz rzeczywiście składa się z bloków 2x2 pikseli.

Gdy używasz rozdzielczości 2560 * 1440 z powiększeniem 200%, każdy obiekt jest najpierw skalowany , a następnie renderowany w pełnej rozdzielczości. W przypadku bitmapy może to nie mieć znaczenia, ale obiekty takie jak czcionki TrueType lub grafika wektorowa skalują się „płynnie”, mogą zmieniać każdy dostępny piksel osobno. W rezultacie powstały obraz niekoniecznie tworzy bloki 2x2 pikseli na ekranie, jak w pierwszym przypadku.

Przykład

1. Zacznijmy od niskiej rozdzielczości 4x4:

   

2. Rysujemy obiekt opisany jako „prawy górny lewy trójkąt, 4x4, czarny”:

   

3. Monitor pobiera powyższą mapę bitową i skaluje ją do swojej natywnej rozdzielczości 8x8, więc każdy oryginalny piksel staje się blokiem 2x2 pikseli:

   

4. Teraz używajmy rozdzielczości 8x8 od samego początku:

   

5. Uważamy obiekt opisany jako „górny lewy prawy trójkąt, 4x4, czarny”:

   

6. Mówimy jednak systemowi operacyjnemu, aby używał powiększenia 200%. System operacyjny ponownie oblicza obiekt i otrzymuje „prawy górny lewy trójkąt, 8x8 , czarny”:

   

   To jest następnie wysyłane do monitora i wyświetlane.

Porównanie:

Zauważ, że gdybyśmy mieli oryginalny trójkąt 4x4 jako bitmapę , końcowy wynik byłby taki jak lewy powyżej, niezależnie od tego, czy skalowanie zostało wykonane przez system operacyjny czy monitor. Matematyczny opis trójkąta pozwolił systemowi operacyjnemu przeliczyć go do nowych wymiarów i uzyskać gładki obraz na końcu.

W nowoczesnych systemach operacyjnych wiele elementów GUI, czcionek itp. Jest dostępnych jako „opisy matematyczne”, które można płynnie przeliczyć na podane wymiary (powiększone). Ogólny termin to grafika wektorowa .

Oprócz doskonałej odpowiedzi Kamila (grafika i tekst zostaną narysowane w ulepszonej rozdzielczości, a zatem wyglądają lepiej), MacOS i iOS faktycznie pozwalają programistom na użycie różnych kompozycji w zależności od rozdzielczości ekranu. Na powiększonym ekranie możesz użyć kompozycji z dodatkowymi szczegółami, których nie można odczytać na wyświetlaczu o niższej jakości, i użyć kompozycji z mniejszą liczbą szczegółów na ekranach o niższej jakości.

Na przykład w edytorze tekstu możesz mieć ikonę do tworzenia list numerowanych. Na ekranie o wysokiej rozdzielczości ikona ta zawiera małe cyfry 1, 2, 3, które są prawie czytelne. Gdyby to było zmniejszone do ekranu o niskiej rozdzielczości, byłoby to po prostu rozmycie, więc dla niskiej rozdzielczości używana jest ręcznie zaprojektowana ikona niższej rozdzielczości.

Twoje pierwsze zdjęcie ma 2511 x 1151 pikseli. Czcionki są wyraźnie renderowane w pełnej rozdzielczości, a nie w połowie rozdzielczości, więc „200% zoom” dotyczy tylko skali renderowania, a nie jego zawartości (chyba że treść jest dostępna tylko jako mapa bitowa w oryginalnej rozdzielczości) . Twój obraz jest lepszy niż się spodziewałeś.

Teraz, zakładając, że skalujemy wstępnie wstępnie przesłaną zawartość (mogę to zrobić na moim komputerze za pomocą przewijania ALT zamiast przewijania CTRL, ale nie wiem, jak powszechne może być to na komputerach innych niż XFCE), możesz napotkać odwrotną sytuację: wstępnie wyrenderowane treści wyglądają gorzej niż w oryginalnej skali.

W takim przypadku możesz zobaczyć efekty renderowania subpikseli. Krótko mówiąc, czerwone, zielone i niebieskie podpiksele znajdują się w nieco innych lokalizacjach, a renderowanie podpikseli zawiera te informacje do renderowania kształtów, które są nieco lepsze niż te renderowane bez tej wiedzy. Oczywiście podczas skalowania w górę, drukowania lub oglądania na ekranie o różnych specyfikach kolorystycznych zależność subpikseli zamiaru renderowania nie jest już ważna, a wyniki mogą wyglądać gorzej niż chcesz.

W pewnym sensie jest to wariant „blokowego” wyglądu podczas renderowania na urządzeniu z dokładniejszymi prostokątnymi pikselami niż to, co było zamierzonym urządzeniem wyświetlającym.