Как определить причину низкой производительности HTML5 Canvas? - PullRequest
3 голосов
/ 20 июня 2010

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

Вторая часть моего вопроса: как рассчитать холст fps? Вот как я это сделал, мне кажется логичным, но я тоже могу быть абсолютно неправ. Это правильный способ сделать это?

var fps = 0;  
setInterval(draw, 1000/30);  
setInterval(checkFps, 1000);  

function draw() {  
   //...  
   fps++;  
}  

function checkFps() {  
   $("#fps").html(fps);  
   fps = 0;  
}

Edit: Согласно комментариям Натана, я заменил вышесказанное следующим:

var lastTimeStamp = new Date().getTime();  
function draw() {  
    //...  
    var now = new Date().getTime();  
    $("#fps").html(Math.floor(1000/(now - lastTimeStamp)));  
    lastTimeStamp = now;  
}

Так как этот? Вы также можете рассчитать только разницу в мс с момента последнего обновления, различия в производительности также можно увидеть таким же образом. Кстати, я также провел параллельное сравнение этих двух, и они обычно двигались вместе (разница не более 2), однако у последнего были большие пики, когда производительность была необычайно низкой. 1011 *

Ответы [ 3 ]

2 голосов
/ 20 июня 2010

Ваш код FPS определенно неверен

setInterval(checkFps, 1000);  

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

function checkFps() {  
   $("#fps").html(fps);  
   fps = 0;  
}

неверно (если fps равен 32, то возможно, что у вас есть 32 кадра за 1,5 с (экстремальный случай))

, чтобы увидеть, что было в реальном времени с моментаПоследнее обновление и вычисление в реальном времени / кадров (я уверен, что JavaScript имеет функцию, чтобы получить время, но я не уверен, будет ли оно достаточно точным = мс или лучше)

fps, кстати, не очень хорошоимя, оно содержит количество кадров (с момента последнего обновления), а не количество кадров в секунду, поэтому кадры будут более подходящим именем.

Таким же образом

setInterval(draw, 1000/30);

неправильно, так как вы хотите получить FPS равным 30, но так как setInterval не очень точен (и, вероятно, будет ждать дольше, чем вы говорите, вы получите более низкий FPS, даже если процессор способен справиться с нагрузкой)

1 голос
/ 28 октября 2010

Проверьте, не используете ли вы какой-либо метод innerHTML для отладки вашего проекта. Это может замедлить ваш проект таким способом, который вы не можете себе представить, особенно если вы делаете некоторую конкатенацию, например, innerHTML + = newDebugValues;

Или, как сказал Десау, профилируйте использование своего процессора с помощью внутреннего отладчика firebug или webkit.

1 голос
/ 20 июня 2010

Webkit и Firebug предоставляют инструменты для профилирования, чтобы увидеть, сколько циклов ЦП тратится в вашем коде javascript. Я бы рекомендовал начать там.

Что касается расчета FPS, я не думаю, что ваш код будет работать, но у меня нет хороших рекомендаций: (* ​​1003 *

Причина: большинство (все?) Браузеры используют выделенный поток для запуска javascript и другой поток для запуска обновлений пользовательского интерфейса. Если поток Javascript занят, поток пользовательского интерфейса не будет запущен.

Таким образом, вы можете запустить некоторый код зацикливания JavaScript, который будет «обновлять» пользовательский интерфейс 1000 раз подряд (например, устанавливая цвет некоторого текста) - но если вы не добавите setTimeout, чтобы позволить потоку пользовательского интерфейса рисовать изменить, вы не увидите никаких изменений, пока 1000 итераций не будут завершены.

Тем не менее, я не знаю, сможете ли вы уверенно увеличить свой счетчик fps в конце процедуры draw (). Конечно, ваша функция javascript завершена, но браузер действительно рисовал?

...