Właściwości obliczania interwału Timera

Czy interval timera jest liczony w sposób ciągły czy od zakończenia zadania?

z założenia w sposób ciągły, ALE jeśli zadanie trwa dłużej niż interwał to następny raz zostanie uruchomione dopiero jak skończy się wykonywać poprzednie wywołanie ponieważ timer (jego część związana ze zdarzeniem OnTimer) działa w wątku głównym. No chyba, że w zdarzeniu OnTimer uruchamiasz wątek albo mas Application.ProcessMessages.

I jeszcze ważna uwaga - na Windowsach rozdzielczość tego timera jest bardzo mocno ograniczona i (nie pamiętam dokładnie) poniżej kilkunastu/kilkudziesięciu ms to właściwie wychodzi na jedno, niezależnie od tego, co wpiszesz w pole interval. Na Linuksie to działa zupełnie inaczej - niedawno miałem mały problem, bo zrobiłem model aplikacji na Linuksie (pisałem w Lazarusie, więc jest to w pełni przenośne między platformami) i okazało się, że pewne animacje menu, które na Linuksie były super, na Windowsie działały tak z 10x wolniej.

Może @furious programming będzie miał coś do dodania, bo pamiętam, że walczył z timerami i precyzyjnym odmierzaniem czasu podczas tworzenia platformersa.

Pamiętaj o tym, że timer jest uzależniony od aplikacji działających w tle. /oraz/ Kiedy na przykład aplikację chcesz na belce przesunąć timer zatrzyma się. Bo nie zadziała application.ProcessMessages - problem z odświeżaniem. Masz wrażenie, że muli i Twoja aplikacja jest niestabilna. Kiedy przytrzymasz belkę np. przez godzinę Twoja aplikacja jest martwa właśnie o ten czas wykonania procedury. Do tego służą watki. Tam interwał jest niezależny od klikania oraz aplikacji działających w tle. Jeśli oczywiście uruchomisz ustaw priorytet aplikacji.

cerrato napisał(a):

I jeszcze ważna uwaga - na Windowsach rozdzielczość tego timera jest bardzo mocno ograniczona i (nie pamiętam dokładnie) poniżej kilkunastu/kilkudziesięciu ms to właściwie wychodzi na jedno, niezależnie od tego, co wpiszesz w pole interval.

Nie powiedziałbym, że jest „mocno ograniczona”, bo minimum wynosi w przybliżeniu 10 lub 16 milisekund, co daje rozdzielczość rzędu od 64 do 100 wywołań na sekundę, co w większości przypadków w zupełności wystarcza. ;)

Ale fakt, takie minimum jest określone i wywołanie np. Sleep(1) nie da przerwy trwającej milisekundę.

Może @furious programming będzie miał coś do dodania, bo pamiętam, że walczył z timerami i precyzyjnym odmierzaniem czasu podczas tworzenia platformersa.

Zgadza się – AFAIR przy okazji wpisów na temat platformera, we wpisie dołączyłem tabelkę pokazującą minimalne interwały na różnych systemach – WinXP, Win7 oraz Win10. I z tego co pamiętam, WinXP wypadał najlepiej, czyli posiadał najmniejszy interwał, przekładający się na największą liczbę wywołań per sekunda.

Jednak to, że minimum jest ustalone, wcale nie oznacza, że nie można go zmienić. Każdy system/hardware posiada hardkodowany minimalny interwał, który można wykorzystać. Aby pobrać obsługiwane minimum, należy skorzystać z funkcji TimeGetDevCaps, a następnie wykorzystać tę wartość do ustawienia rozdzielczości pracy schedulera (albo jak się to tam nazywa) za pomocą funkcji TimeBeginPeriod. W platformerze robię to tak:

procedure TClock.InitSystemTimerPeriod();
var
  Periods: TTimeCaps;
begin
  if TimeGetDevCaps(@Periods, SizeOf(Periods)) = TIMERR_NOERROR then
  begin
    FTimerPeriod := Periods.wPeriodMin; // z reguły 1, czyli dokładność co do 1ms
    TimeBeginPeriod(FTimerPeriod);
  end
  else
    FTimerPeriod := -1;
end;

Na koniec pracy naszej aplikacji należy przywrócić poprzednią rozdzielczość:

procedure TClock.DoneSystemTimerPeriod();
begin
  if FTimerPeriod <> -1 then
    TimeEndPeriod(FTimerPeriod);
end;

Uniksy mają lepszy system odmierzania czasu – nie trzeba się martwić o rozdzielczość, bo istnieje funkcja nanosleep (we Free Pascalu ma nazwę FPNanoSleep), która obsługuje nawet mikrosekundowe interwały. Tę wykorzystałem w platformerze do odmierzania przerw pomiędzy klatkami i działa perfekcyjnie.

​
Gdyby ktoś potrzebował zobaczyć jak wygląda klasa mojego timera, to jego źródła są publicznie, a najświeższe źródła są w tym poście (moduł Platformer.Time.pp, klasa TClock).

Klasa zegara jest uniwersalna i można ją wykorzystać w dowolnym projekcie, w którym potrzeba wykonywać dane zadanie cyklicznie, z dużą dokładnością wywołań. Nadaje się do gier oraz podobnych projektów. Sam używam jej w Deep Platformerze, a także w projekcie Richtris (miałem też w CTCT, ale zakończyłem jego rozwój). @Crow chyba korzysta z niej w swoim projekcie silnika 3D do swojej gry. No i chłopaki z forum Free Pascala też czerpią z niej wiedzę, więc uważam ją za wartą uwagi.

Zaznaczam jednak, że przeznaczeniem mojej implementacji zegara jest odzwierciedlenie pracy konsoli NES. Jeśli zegar spóźni się (np. obsługa klatki gry trwała dłużej niż przeznaczony dla niej czas, np. 16ms), to zegar pominie spóźnione wywołanie i poczeka na kolejne. Ujmując to prostymi słowami, dostaniemy laga, a framerate spadnie. Czyli w sumie jego zachowanie jest podobne do klasy TTimer, ale posiada przewagę w postaci mikrosekundowej precyzji.

​
Wracając do meritum – Sleep raczej nie ma wiele wspólnego z systemowymi timerami (i klasą TTimer), więc potraktujcie mój post jedynie jako ciekawostkę (odpowiedź na przywołanie mnie). W razie czego zainteresujcie się timerami multimedialnymi – informacje znajdziecie w dokumentacji. ;)

Bruno(M) napisał(a):

Pamiętaj o tym, że timer jest uzależniony od aplikacji działających w tle. /oraz/ Kiedy na przykład aplikację chcesz na belce przesunąć timer zatrzyma się. Bo nie zadziała application.ProcessMessages - problem z odświeżaniem. Masz wrażenie, że muli i Twoja aplikacja jest niestabilna. Kiedy przytrzymasz belkę np. przez godzinę Twoja aplikacja jest martwa właśnie o ten czas wykonania procedury. Do tego służą watki. Tam interwał jest niezależny od klikania oraz aplikacji działających w tle. Jeśli oczywiście uruchomisz ustaw priorytet aplikacji.

Jakiś czas temu pisałem jeden program w C++ z Qt, on też używał timera i miałem dokładnie taki sam problem. Doczytałem, że to nie jest cecha samego Qt, tylko cecha Windowsa. W tym przypadku nie było konieczne dokładne odmierzanie czasu (tolerancja nawet 20% interwału to żaden problem), ale przerwa trwająca kilka interwałów powodowała problem z aplikacją.

Timer to jest obiekt jak każdy inny. Ten problem przestał istnieć, jak utworzyłem i uruchomiłem timer w innym wątku i utrzymywałem referencję do tego obiektu na stercie, aby mieć do niego dostęp. Tak przygotowany timer taktował również podczas przesuwania i zmiany rozmiaru okna aplikacji, można było też zminimalizować aplikację i timer dalej działał. Inną sprawą jest dostęp do formatki, o ile w ramach czynności wykonywanych w zdarzeniu timera jest potrzebny dostęp do formy.

andrzejlisek napisał(a):

Jakiś czas temu pisałem jeden program w C++ z Qt, on też używał timera i miałem dokładnie taki sam problem. Doczytałem, że to nie jest cecha samego Qt, tylko cecha Windowsa.

Gdzie o tym doczytałeś?

Timer to jest obiekt jak każdy inny. Ten problem przestał istnieć, jak utworzyłem i uruchomiłem timer w innym wątku […]

W takim razie po co Ci timer, skoro i tak wydzielasz logikę do osobnego wątku? To co robisz jest bez sensu.

[…] i utrzymywałem referencję do tego obiektu na stercie, aby mieć do niego dostęp.

To nie ma akurat żadnego znaczenia. Zresztą nie da się utworzyć instancji klasy na stosie – wszystko ląduje na stercie, nieważne czy jest to lokalna instancja tworzona gdzieś wewnątrz jakiejś metody, czy instancja globalna, tworzona automatycznie przez klasę formularza (timer jako komponent na formie).

Tak przygotowany timer taktował również podczas przesuwania i zmiany rozmiaru okna aplikacji, można było też zminimalizować aplikację i timer dalej działał.

Zmartwię was, ale podstawowy timer w Lazarusie działa bez względu na to czy okno jest widoczne czy zminimalizowane, czy przesuwamy formularz czy nie. Ba, nawet jeśli wywołam sobie dialog modalnie, to timer (pomimo bycia w klasie okna przyblokowanego) i tak robi swoje, nie zatrzymuje się.

Jestem tego pewny, dlatego że wykorzystałem zwykły timer do animowania banera w swoim oprogramowaniu CTCT i działa tak jak opisuję. Żadnych problemów – operator robi sobie co chce, otwiera okna modalne, dłubie to co potrzebuje, a timer ładnie animuje baner w okienku teł. W załącznikach tego posta jest tester działania animowanego banera – można sobie sprawdzić.

Jeśli nie działa wam to w Delphi czy w C++, to winny nie jest system, a VCL i QT.

furious programming napisał(a):

andrzejlisek napisał(a):

Jakiś czas temu pisałem jeden program w C++ z Qt, on też używał timera i miałem dokładnie taki sam problem. Doczytałem, że to nie jest cecha samego Qt, tylko cecha Windowsa.

Gdzie o tym doczytałeś?

Gdzieś na StackOverflow czy innym podobnym forum ktoś to napisał i że na Linux tego problemu nie ma, to było może 5 lat temu. Po wpisaniu w Google kilku odpowiednich zapytań do tego dotarłem. Dla mnie istotne było, z czego wynika problem, a nie gdzie to było napisane. Teraz jakoś nie mogę do takiej informacji dotrzeć, albo mi się coś pomyliło.

Timer to jest obiekt jak każdy inny. Ten problem przestał istnieć, jak utworzyłem i uruchomiłem timer w innym wątku […]

W takim razie po co Ci timer, skoro i tak wydzielasz logikę do osobnego wątku? To co robisz jest bez sensu.

Chodziło o uruchamianie pewnego kawałka kodu w (mniej więcej) stałych odstępach czasu. Timer był najprostszą rzeczą, którą użyłem, a dopiero później zauważyłem, że on nie działa podczas przesuwania okna, a w jednym przypadku miało to bardzo duże znaczenie. Najmniej inwazyjną metodą było przeniesienie timera do osobnego wątku. Po prostu spróbowałem, czy to rozwiąże problem i rozwiązało. Gdybym od początku wiedział, że QTimer na Windows ma taki problem, to od razu bym poszukał innego, lepszego sposobu.

[…] i utrzymywałem referencję do tego obiektu na stercie, aby mieć do niego dostęp.

To nie ma akurat żadnego znaczenia. Zresztą nie da się utworzyć instancji klasy na stosie – wszystko ląduje na stercie, nieważne czy jest to lokalna instancja tworzona gdzieś wewnątrz jakiejś metody, czy instancja globalna, tworzona automatycznie przez klasę formularza (timer jako komponent na formie).

Tak przygotowany timer taktował również podczas przesuwania i zmiany rozmiaru okna aplikacji, można było też zminimalizować aplikację i timer dalej działał.

Zmartwię was, ale podstawowy timer w Lazarusie działa bez względu na to czy okno jest widoczne czy zminimalizowane, czy przesuwamy formularz czy nie. Ba, nawet jeśli wywołam sobie dialog modalnie, to timer (pomimo bycia w klasie okna przyblokowanego) i tak robi swoje, nie zatrzymuje się.

Jestem tego pewny, dlatego że wykorzystałem zwykły timer do animowania banera w swoim oprogramowaniu CTCT i działa tak jak opisuję. Żadnych problemów – operator robi sobie co chce, otwiera okna modalne, dłubie to co potrzebuje, a timer ładnie animuje baner w okienku teł. W załącznikach tego posta jest tester działania animowanego banera – można sobie sprawdzić.

Jeśli nie działa wam to w Delphi czy w C++, to winny nie jest system, a VCL i QT.