Браузеры отображают элементы холста, которые не находятся внутри области просмотра?

Question

У меня есть страница, на которой выполняются довольно тяжелые (скорее, средние) операции canvas.Для обслуживания пользователей на мобильных устройствах и старых компьютерах я подумал, что мог бы реализовать механизм, который будет проверять, действительно ли элемент canvas виден, и решать, нужно ли выполнять постоянные вычисления и обновления холста (анимация, работающая со скоростью 30 кадров в секунду) или нет.

Это работает нормально, но при выполнении теста производительности с помощью инструментов Chrome Dev я заметил, что даже когда я отключаю свою проверку видимости и просто позволяю вещам все время рендериться, использование ЦП рассматриваемой функции падаетсовсем немного, когда никакая часть элемента (ов) холста не видна (хотя в теории он все еще должен выполнять те же задачи).Итак: по крайней мере, на моем компьютере с Chrome 17 не будет никакой разницы, если я проверю фактическую видимость элемента.

Короче говоря: нужно ли это делать или браузеры достаточно умныразобраться с таким случаем, даже не сказав им (и я могу сохранить проверку видимости)?

---

РЕДАКТИРОВАТЬ :

Поэтому я провел "исследование"эта тема и построена эта скрипка.

Что происходит, так это то, что он просто генерирует шум со скоростью 30 кадров в секунду.Не слишком приятно для глаз, но, ну ... Верхняя часть - это просто div, чтобы заблокировать окно просмотра.Когда я прокручиваю вниз и вижу элемент canvas в окне просмотра, загрузка процессора говорит мне, что он занимает около 40%, так что, видимо, браузер действительно должен здесь многое сделать.Когда я прокручиваю назад вверх, чтобы в моем окне просмотра был выделен бордовый цвет div и профилировал загрузку процессора, он упал до 10%.Когда я прокручиваю назад вниз: использование снова возрастает.

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

Так что мне все еще интересно, является ли это побочным эффектом чего-то, чтоЯ не знаю (или я делаю какую-то серьезную ошибку при профилировании) или могу ли я ожидать, что браузеры будут достаточно умными, чтобы справляться с такими ситуациями?

Если бы кто-то мог пролить свет на это, я бы оченьблагодарны!

Answer 1

Я думаю, вы не понимаете, работает ли логика и происходит ли рендеринг .Многие браузеры теперь аппаратно ускоряют свои полотна, поэтому весь рендеринг происходит на графическом процессоре, поэтому фактическое нажатие пикселей в любом случае не занимает процессорного времени.Однако ваша тиковая функция имеет нетривиальный код для генерации случайного шума на процессоре.Так что вас действительно беспокоит, работает ли функция галочки.Если холст за кадром, он точно не будет отображаться на экране (он не виден).Что касается вызовов холста, это, вероятно, зависит от браузера.Он может отображать все вызовы отрисовки на холсте за пределами экрана в случае, если вы вдруг прокрутите его обратно для просмотра, или он может просто поставить в очередь все вызовы отрисовки и фактически ничего с ними не делать, пока вы не прокрутите холст для просмотра.Я не уверен, что там делает каждый браузер.

Однако, вы не должны использовать setInterval или setTimeout для анимации Canvas .Используйте новый requestAnimationFrame API.Браузеры не знают, что вы делаете при вызове по таймеру, поэтому всегда будут вызывать таймер.requestAnimationFrame, с другой стороны, разработан специально для визуальных вещей, поэтому браузер имеет возможность не вызывать функцию тика или снижать скорость, с которой она вызывается, если холст или страница не видны.

Что касается того, как браузеры на самом деле справляются с этим, я не уверен.Однако вам определенно следует предпочесть его, поскольку будущие браузеры могут лучше оптимизировать requestAnimationFrame способами, которые они не могут оптимизировать setInterval или setTimeout.Я думаю, что современные браузеры также уменьшают обычные таймеры до 1 Гц, если страница не видна, но браузеру определенно намного проще оптимизировать requestAnimationFrame, плюс некоторые браузеры обеспечивают вам V-синхронизацию и другие преимущества с ним.

Так что я не уверен, requestAnimationFrame будет означать, что ваша функция галочки не вызывается, если холст прокручивается вне поля зрения.Поэтому я бы рекомендовал использовать и requestAnimationFrame и существующую проверку видимости.Это должно гарантировать вам самый эффективный рендеринг.

Answer 2

Исходя из моего собственного опыта, он отображает все, что вы скажете, независимо от положения на экране.

Например, если вы рисуете плитки, размер которых превышает размер холста, вы все равно увидите снижение производительности, если вы неоптимизируйте скрипт.

Попробуйте свою функцию с анимацией, требующей высокой производительности, и посмотрите, получите ли вы те же результаты.