Планирование обновления «потоков» в JS / WebGL - PullRequest
2 голосов
/ 09 января 2012

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

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

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

1 Ответ

3 голосов
/ 09 января 2012

setTimeout и setInterval не особенно подходят для времени автономной работы и потребления процессора

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

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

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

...