10 komentáře “JavaScript timers – naše staré hodiny, bijí čtyři hodiny

  1. Narůstajícího zpoždění možná, nikoliv však přesné zobrazení času v konkrétním okamžiku. Navíc se mi zdá, že třeba Firefox podobnou logiku uplatňuje již na setInterval – když na testovacím skriptu sleduji zpoždění, tak pokud naroste, tak se po nějaké chvíli zase sníží. Ale možná je to jen klam.

    Koukal jsem na ten kód, co uvádíte, a nepovedlo se mi vyextrahovat, jak by se choval v případě, že by zpoždění přesáhlo celý sledovaný interval. Tzn. kdyby v okamžiku N bylo zpoždění 0ms a v okamžiku N+1 třebas +1300ms, přičemž námi sledovaná perioda je 1000ms. Pak byste se totiž dostal do situace, kdy byste potřeboval další timeout nastavit na -300ms, což nepůjde.

  2. Pochopil jsem co jste měl na mysli. Spíš na to reaguji ve smyslu – přestože v daném okamžiku víte, že máte zpoždění 50ms a načasujete tedy další timer na 950ms místo 1000s nikde nemáte zaručeno, že se vám timer skutečně zavolá za 950ms a ne třeba až za 1300ms. Podle mého názoru tím daný problém neřešíte.

  3. Podle mého názoru setTimeout trpí úplně stejnými nešvary jako setTimeout – princip je úplně stejný – jen setInterval se provádí opakovaně a setTimeout jedinkrát. Na vině je jednovláknovost prohlížeče, se kterou voláním jiné metody nic nezískáme. Každopádně díky za reakci.

  4. Abych pravdu řekl, nezkoušeli. Současná přesnost je pro nás dostačující – rozdíly mezi uživateli nejsou už rozpoznatelné. Ale je to zajímavý nápad.

  5. Nezouseli jste zmerit, jestli doba „mezi vložením času do HTTP response a zpracování HTTP response“ odpovida zhruba polovine casu od odeslani requestu z klienta po zpracovani response? Pak by se to mozna mohlo ješte upravovat o tuto konstantu.

  6. Ten zaver do kamene tesat. Takhle naivni jsem i pres svuj seniorsky vek docela casto. Sam pred sebou se omlouvam slovy „Po bitve je kazdej general“.

    Diky za clanek.