Планирование обновления «потоков» в JS/WebGL

Question

В настоящее время я передаю содержимое WebGL с использованием requestAnimationFrame, который работает в (идеально) 60 FPS. Я также параллельно планирую процесс «обновления», который обрабатывает AI, физику и т. Д., Используя setTimeout. Я использую последнее, потому что мне действительно нужно обновлять объекты примерно 30 раз в секунду, и это не является частью последовательности рисования; было бы неплохо сохранить оставшийся процессор для фактических проходов рендеринга, так как большинство моих анимаций довольно интенсивно аппаратно.

Мой вопрос является одним из лучших практик. setTimeout и setInterval не особенно подходят для работы от батареи и потребления процессора, особенно если браузер не находится в фокусе. С другой стороны, использование requestAnimationFrame (или привязка обновлений непосредственно к существующей фазе визуализации) потенциально обеспечит гораздо больше обновлений каждую секунду, чем это абсолютно необходимо, и может полностью перестать обновляться, когда браузер не находится в фокусе или в другое время браузер считает «ненужным» для «анимации».

Что является лучшим средством для обновления, но не рендеринга контента?

Answer 1

SetTimeout и setInterval не особенно любезны жизни батареи и процессора потребления

Давайте будем честными: Ни один не requestAnimationFrame. Разница в том, что RAF автоматически отключается, когда вы покидаете вкладку. Это поведение можно эмулировать с помощью setTimeout, если вы используете Page Visibility API, хотя на самом деле проблемы с энергопотреблением между ними примерно равны, если использовать их разумно.

Помимо этого, setTimeout\Interval идеально подходит для использования в вашем случае. Единственное, что вы, возможно, захотите знать, это то, что вам будет трудно получить его в полном соответствии с циклом рендеринга. У вас будут случаи, когда вы можете нарисовать один или несколько раз до того, как ваше обновление анимации ударит, что может привести к незначительному заиканию. Если вы выполняете рендеринг на 60 Гц и обновляете его с частотой 30 Гц, это не должно быть большой проблемой, но вы хотите знать об этом.

Если вы прекрасно синхронизированы с циклом рендеринга, вы можете просто иметь if(framecount % 2) { updateLogic(); } в верхней части вашего обратного вызова RAF, что эффективно ограничивает ваши обновления до 30 Гц (каждый другой фрейм), и он всегда синхронизируется с ничья.