Witajcie w kolejnym odcinku. Wiele razy pewnie spotkaliście się z tym, jakie to wyświetlacze 120 Hz są super płynne i w ogóle. Tylko o co w tym właściwie chodzi i dlaczego to takie ważne? W tym artykule postaram się wyjaśnić wszystkie wątpliwości, a dodatkowo pokazać, jak wygląda sytuacja z perspektywy programisty.
Zacznijmy od podstaw, czyli co się kryje za wyświetlaczem 120 Hz?
Wspomniany już wyżej Herc (Hz) to jednostka miary częstotliwości zdarzenia. 1 Hz to dokładnie 1 zdarzenie, które występuje co sekundę, 100 Hz to 100 takich wydarzeń w tym samym czasie i tak dalej. Tak więc jeśli mówimy o częstotliwości odświeżania ekranu, to mamy na myśli liczbę możliwych zmian obrazu na sekundę. Standardowe wyświetlacze (również w naszych smartfonach) oferują częstotliwość odświeżania 60 Hz. Oznacza to, że w ciągu sekundy są w stanie wyświetlić maksymalnie 60 różnych klatek.
Jeśli czytaliście mój artykuł o tworzeniu interfejsów, natrafiliście pewnie na informację, że Android odświeża klatki dokładnie co 16 ms. Skąd się wzięła ta liczba? Już tłumaczę. Jeśli mamy ekran o częstotliwości 60 Hz, to jesteśmy w stanie wyświetlić 60 klatek w czasie jednej sekundy. 1 sekunda to 1000 ms, a więc jeśli podzielimy 1000 przez 60, to wychodzi nam ~ 16 (przy zastosowaniu zaokrąglenia w dół).
Zobacz też: Jak zwiększyć swoje szanse w rozmowie o pracę?
16 ms to wartość, którą my jako programiści mamy do dyspozycji w celu wyrysowania pojedynczej klatki. Z reguły nie musimy się tym przejmować, ponieważ rzadko piszemy coś na tyle specyficznego, żeby bezpośrednio dotykać układów graficznych. Jednak musimy pamiętać, żeby nie wykonywać czasochłonnych operacji na głównym wątku, bo możemy łatwo przekroczyć 16 ms i w rezultacie stracić kilka klatek, co prowadzi do brzydkich efektów wizualnych.
Warto jeszcze wyjaśnić, że FPS (frames per second – klatki na sekundę) nie są sztywno związane z częstotliwością odświeżania ekranu. Na przykład na monitorze 120 Hz możemy renderować klatki tylko w co drugim „możliwym okienku” i finalnie będziemy mieli 60 FPS. Samo posiadanie odpowiedniego ekranu nie oznacza jego stałej pracy w wysokiej częstotliwości odświeżania.
Skąd wzięła się wartość 60 FPS?
Koncepcja ruchu w cyfrowych ekranach jest pewnego rodzaju hakiem na naszych oczach (a raczej mózgu). Monitory tak naprawdę nie wyświetlają ruchomych rzeczy, tylko pojedyncze nieruchome obrazy w krótkich odstępach czasowych. Badania wykazały, że już powyżej 10 klatek na sekundę takie obrazy „zlewają” nam się, dając iluzję ruchu. Jednak taka wartość to zbyt mało, aby animacje wydawały się w pełni płynne.
Z kolei wartość 60 FPS leży na drugim biegunie. Przy takiej częstotliwości animacje wydają nam się niesamowicie płynne. Dodatkowo większość ludzi nie zauważa różnicy między 60 FPS i wyższymi wartościami. Jest to wniosek mocno uproszczony, ponieważ w przypadku szybkich ruchów kamery, na przykład w grach, ta różnica jest już zauważalna. Jednak uznano, że 60 klatek na sekundę jest odpowiednim balansem pomiędzy kosztami a efektami wizualnymi.
Pewnie teraz będzie was kusić, żeby przekonać się na własne oczy, czy nie zauważycie różnicy pomiędzy 60 FPS i 120 FPS. Pamiętajcie jednak, że większość ekranów działa w 60 Hz.
Co nam dają wyświetlacze 120 Hz?
Na wstępie chciałbym zaznaczyć, że podane niżej czasy dostępne dla pojedynczej klatki są czasami modelowymi, wynikającymi z możliwości czysto sprzętowych. Czasami można je wydłużyć na przykład przy pomocy „render ahead” – techniki znanej z gier wideo.
Jednak przejdźmy do pytania z nagłówka. Oczywistym benefitem jest to, że możemy wyświetlać obraz w 120 klatkach na sekundę, ale to nie wszystko. Wbrew pozorom 120 Hz może nam pomóc, gdy nasza aplikacja jest na tyle ciężka, że nie jesteśmy w stanie wyświetlić nawet 60 klatek na sekundę. Jak to możliwe?
Pamiętacie wartość 16 ms? Był to czas dostępny na wyświetlenie pojedynczej klatki. Jeśli byśmy go przekroczyli nawet o 1 ms, to musimy czekać na kolejne „okienko”. Czyli jeśli nasza aplikacja jest dość ciężka i potrzebuje 17 ms na stworzenie klatki, to przy częstotliwości 60 Hz będziemy mogli wyświetlać obraz, tylko w co drugim okienku czasowym. Wobec czego nasza aplikacja będzie działać w 30 fps, ponieważ nowa klatka będzie się pojawiać co 32 ms.
Nieco inaczej ma się sprawa przy 120 Hz. W tym wypadku kolejne klatki będziemy mogli wyświetlać co 8 ms (1000 / 120 = ~ 8 ms). Z pozoru wydaje się, że dla programisty jest to sytuacja gorsza, ponieważ mamy mniej czasu, dostępnego na stworzenie klatki. Jednak nie do końca, bo możliwość wyświetlenia klatki co 8 ms, daje nam większą swobodę. W przypadku naszej przykładowej aplikacji, wymagającej 17 ms na stworzenie klatki, możemy ją wyświetlać co 24 ms, a nie 32 ms jak w przypadku 60 Hz. Dzięki temu nasz obraz będzie mógł działać w ~ 40 FPS, zamiast 30 FPS.
Wyświetlacze 120 Hz a odtwarzanie filmów
W jednym z poprzednich akapitów mogliście przeczytać, że 60 FPSjest złotym środkiem, jeśli chodzi o płynność animacji i koszt w kontekście urządzeń cyfrowych. W branży filmowej odpowiednikiem takiej wartości jest 24 FPS. Większość filmów jest kręconych właśnie przy takim klatkowaniu. Jednak tutaj pojawia się problem, gdy nasz wyświetlacz pokazuje obraz w 60 Hz. Jeśli na takim ekranie chcielibyśmy wyświetlić obraz w 24 klatkach, to musielibyśmy pokazywać go dokładnie co 2.5 okienka czasowego (60 / 24 = 2.5), a to jest niemożliwe. Tutaj na pomoc przychodzi technika 3:2 pull down, która umożliwia rozciągnięcie każdych 4 klatek do 5, co sprowadza nam film do ~ 30 FPS, jednocześnie pogarszając trochę jakość obrazu. Przy 120 Hz problem znika, ponieważ 24 klatki są wspierane natywnie. W takiej sytuacji klatka renderowana jest dokładnie co 5 okienek czasowych (120 / 24 = 5). Dzięki temu nie musimy korzystać już z żadnych algorytmów i mamy ładniejszy obraz.
Czy jako programiści mamy wpływ na częstotliwość odświeżania obrazu?
Jeśli chciałbym odpowiedzieć krótko, powiedziałbym tak:
W naszej aplikacji mamy kilka sposobów na określenie żądanej częstotliwości. W Androidzie 11 możemy skorzystać z Surface.setFrameRate, SurfaceControl.Transaction.setFrameRate, lub w przypadku aplikacji natywnych ANativeWindow_setRrameRate oraz ASurfaceTransaction_setFrameRate. Jeśli nasz program jest projektowany na niższe wersje Androida, to musimy przypisać odpowiednią wartość do WindowManager.LayoutParams.preferredDisplayModeId.
Teraz może przejdźmy do części „ale jednak nie do końca”. Ponieważ w rzeczywistości system traktuje nasze żądania jedynie jako wskazówki i to Android finalnie decyduje, jaką częstotliwość wybrać. Ma to jednak głębszy sens. Wyobraź sobie, że oglądasz film w trybie Picture in Picture i jednocześnie używasz Facebooka. Aplikacja odtwarzacza zażądała od Androida 24 Hz w celu poprawnego wyświetlenia wideo. Jeśli Android by się na to zgodził, natychmiast zauważyłbyś klatkujące animacje w aplikacji Facebooka. W takiej sytuacji system wybierze 120 Hz (o ile będzie dostępne), żeby zarówno odtwarzacz mógł działać w 24 FPS, jak i Facebook w domyślnych 60 FPS.
Zobacz też: Dowiedz się wszystkiego o Cyberpunk 2077!
To już wszystko na dziś, dzięki za przeczytanie! Tradycyjnie zapraszam do naszej sekcji programowanie oraz na nasze forum dla programistów. Do zobaczenia i usłyszenia już niedługo!