setInterval замедляется

[Борис К]

Проверь протокол - нужен https.

Протокол https есть, а толку нет!(((

[voraa]

На форуме есть ошибка. С некоторых страниц (в основном с главной) переход в тему осуществляется по http, а не по https.
Сначала с главной надо войти в раздел, а потом в нужную тему.

[ksa]

В тот момент, когда "не дает плюсануть", нужно проверить протокол... Просто дописать s и нажать Enter - тогда будет работать.

Правда будет еще одно ограничение - что-то типа "Вы уже плюсовали его, для его плюсования нужно сначала плюсануть кого-то еще".

[rgl]

Картинка все равно будет обновляться так, как она может. И именно requestAnimationFrame говорит: Выполни эту функцию перед очередным обновлением. От того, что поставить 4мс экран не будет обновлятться быстрее Если у вашего монитора частота 60Гц, то это как раз и будет 1/60 ~ 16.67 мс. Быстрее никак. Медленнее - может быть, если поток занят какой то тяжелой задачей, тогда очередное обновление будет только после ее окончания.

Когда я говорил "успевает за 4ms" имел ввиду что при значениях 4 и больше функция вызывается (и успевает все сделать) примерно с соответствующей частотой. Понятно, что реально видимая картинка никак не может меняться чаще, чем частота монитора. Но вот вопрос - должна ли программа учитывать частоту монитора и работать по разному с разными мониторами? Однозначно ответить тут нельзя, у каждой точки зрения есть свои аргументы за и против.

[Aetae]

rgl, ну на самом деле есть два аргумента, один из которых ультимативный: производить перерасчёт ровно столько раз сколько надо для установленной частоты - гораздо оптимальнее, чем делать это с заданным интервалом, в вашем случае выигрыш по ресурсам будет в 16/4 = 4 раза.
Второй аргумент, если интересно, это то, что таймер рассинхронизирован с кадрами, из-за чего может возникать пропуск кадра и небольшое дёрганье анимации.

[voraa]

Но вот вопрос - должна ли программа учитывать частоту монитора и работать по разному с разными мониторами?

Да. Зачем делать лишние расчеты и изменения в DOM, которые все равно не будут визуализированы?

[rgl]

Оба аргумента в некоторых случаях теряют силу. 4ms - это не рабочее значение а, как бы, проверка на прочность. Мне хотелось быть уверенным что производительности с запасом хватает.
А что если для моей задачи достаточно, скажем, 50 ms? По производительности никакого проигрыша, наоборот, в случае requestAnimationFrame мне нужно делать лишние действия - решать уже пора или еще нет. И дергание анимации может возникнуть, если оба числа близкие, напр. 16 и 20 или 16 и 10, а если они отличаются в разы (в любую сторону, то (с этой точки зрения!) все ОК. Скажем, задаю интервал 50 ms, ну иногда картинка будет меняться каждый пятый кадр, а иногда через 6. Никакого дергания.

[rgl]

Правда будет еще одно ограничение - что-то типа "Вы уже плюсовали его, для его плюсования нужно сначала плюсануть кого-то еще".

И, похоже, не одного

[voraa]

А что если для моей задачи достаточно, скажем, 50 ms? По производительности никакого проигрыша, наоборот, в случае requestAnimationFrame мне нужно делать лишние действия - решать уже пора или еще нет.

Если ваша задача занимает 50 мс, то обновление кадра произойдет через 50мс. Движок не прерывает выполнение задачи для визуализации очередного кадра. Есть четкий цикл выполнения
- Выполнение задачи,
- выполнение микрозадач,
-Если подошло время обновления кадра, то
- выполнение функции из requestAnimationFrame
- перерасчет стилей и компоновка
- визуализация кадра.

Под задачей понимается выполнение обработчиков событий и таймеров
Микрозадачи - выполнение функций исполненных промисов и обсерверов.
И пока задача не будет полностью выполнена, микрозадачи не начнут выполняться. Пока задачи и микрозадачи не будут исполнены, никаких действий по визуализации кадра не будет.

И, кстати, setInterval (f, 4) - не означает выполнить через 4 мс. Это означает поставить в очередь задач через 4 мс. Если в очереди уже есть задачи, которые в сумме выполняются 50мс, то значит функция будет выполнена через 50мс.