FlashMX и тайминги

[ilya_cat]

Приветствую всех уважаемых флешеров.
Предлагаю Вам маленькое исследование по вопросу скорости работы flash.
Все указанные ниже цифры относятся к Celeron 433 (соотношение цифр сохраняется и на более скоростных машинах).
Итак...[list=1][*] Создайте пустой ролик с fps равным 100[*] Положите в первый кадр следующий текст:

var a=new Array();
var x;
maxx=500;
function calc() {
	for (x=0;x<maxx;x++) {
		a[x]=x;
	};
};
time=getTimer();

[*] Во второй и третий кадр положите следующее:

calc();

[*] В четвертый кадр положите следующее:

newtime=getTimer();
fps=(_currentframe-2)*Math.round(100000/(newtime-time))/100;
time=newtime;

[*] Создайте еще один слой, положите в него текстовое поле и привяжите к переменной fps - чтобы глядеть результат[*] Запустили.[/list=1]
Полученное условное значение fps у меня примерно равно 18.
А теперь фокус!
Меняем значение maxx на 100 и дублируем третий кадр восемь раз - у нас теперь десять вызовов calc().
Полученное условное значение fps у меня стало приближаться к 80.
И последний шаг - меняем значение maxx на 1000 и удаляем все кадры с вызовами calc(), кроме второго - у нас теперь только один вызов calc().
Полученное условное значение fps у меня стало около 8.
Заметьте - во всех случаях у нас 1000 проходов по массиву, а время обработки различается в десять раз.

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

[Dendroid]

вот гон-то какой.
Ты чего курил?

[Dendroid]

fps=(_currentframe-2)*Math.round(100000/(newtime-time))/100;

Тебе в AMD надо работать будешь для них тесты придумывать, чтобы они Intel и дальше обгоняли

Начинающим упражнение: что надо исправить, чтобы получить правильные результаты: где-то выигрыш процентов 70% при использовании одного вызова вместо десятка разных....

[ilya_cat]

[list=1][*]Я ничего не курю и не пью алкоголь.[*]Мне нужно было дробное значение fps c точностью до сотых[*]Хотя бы скачайте тестовые примеры и запустите, вместо того, чтобы молоть языком - проверено на десятке компьютеров с разными процессорами - соотношение fps для роликов не меняется.[*]Мой стаж программирования - с 1988 года (могу и прописью - Одна тысяча Девятьсот Восемьдесят Восемь), а с флешем я работаю с 1998 года, когда была еще третья версия. Так что прежде чем вынести эту тему на обсуждение, я досконально все проверил и отвечаю за свои слова.[/list=1]
P.S. Советую с уважением относиться к другим участникам этого форума, иначе они, как и я, все реже будут сюда заглядывать, оставив новичков прозябать в болоте непонятностей.

[Uliana]

Уважаемый ilya_cat, действительно это очень интересный факт!
я давно заметила какие-то непонятки в fps, но протестировать как-то не приходило в голову....
спасибо вам за приведенный тест, на самом деле он очень нагляден и объясняет некоторые вещи...
у меня к вам есть небольшой вопрос, может быть вы сталкивались с такой проблемой: при прокуртке ролика в реальных размерах (т. е. если у него размеры например 550х400 и его прокурчивают в этих же размерах, не увеличивая) торможения в движении объектов не наблюдается, а если развернуть ролик во весь экран, то наблюдается движение объектов рывками. Это происходит на абсолютно разных по мощности машинах одинаково, что на PIV c 2,2 ГГц, то же и на Celeron 500.
Что это? Это особенности флеша или это у меня что-то не правильно сделано?
Причем такое происходит не с одним роликом, а совсеми, где есть движение...
Если знаете, подскажите, пожалуйста...
заранее благодарю...

[ilya_cat]

Милая Ульяна.

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

Но это только мои предположения - детально данный вопрос я не рассматривал.

Еще хочу заметить, что в редакторе флеша скорость работы ролика примерно на 25% ниже, чем при запуске его со страницы или standalone плеером - скорее всего из-за встроенного в редактор механизма отладки. Впрочем, этот факт, думаю, широко известен.

[C2Plus]

newtime=getTimer();
fps=(_currentframe-2)*Math.round(100000/(newtime-time))/100;
time=newtime;

вообще говоря, с таким фпс метром можно получить еще более интересные результаты. Почему минус 2?

fps=(_currentframe-1)*Math.round(100000/(newtime-time))/100;

вообще говоря, на таких коротких замерах как 2-3 кадра слишком высока погрешность чтобы принимать их во внимание.

[Dendroid]

Приношу свои извинения, я не хотел никого обидеть.....
Ты меня просто напугал сперва своими выкладками, ведь если это правда, то вся жизнь прожита зря! И я все всегда делал неправильно....

Я запускал твои примеры, и думаю, что дело тут в некорректном продсчете "условного фпс"

Почему в формуле (забить на константы):

fps=_currentframe*(newtime-time);

и время и _currentframe стоят в знаменателе?
Я так понимаю tps(time per frame - сколько потрачено в среднем на фрейм) = 1/fps = (newtime-time)/_totalframes
(у тебя _currentframe - выполняет ту же роль, т.к. ты считаешь свой fps один раз в последнем кадре).
В любом случаем либо время делиться на количество фреймов либо наоборот! У меня получилось, 70% выигрыша при единственном вызове функции в отличае от множественного вызова (т.е. время получается меньше, а средний fps - больше).

Проверьте кто-нубудь меня, я нигде не наврал?

Если уж бряцать медалями, то у меня тоже есть опыт программирования где-то с 80-х годов прошлого века, и плюс к этому я читаю курс лекций по программированию на Си в Новосибирском Государственном Университете (ну это скорее в качестве хобби...)

2Uliana: падение фпс происходит по той же причине, что и падения фпс в каком-нибудь Quake при переходе на большее разрешение - рисовать приходиться больше пикселов! Тут даже дело не в масштабировании (попробуйте сделать меньше 100% - даже быстрее забегает ), а в самой тормозной операции - антиалиасинге..... Извините, если вторгаюсь в чужой разговор....

[ilya_cat]

Итак, объясню:
Разберем формулу на запчасти.[list=1][*]newtime-time - вопросов не вызывает? Результатом служит что? Сколько миллисекунд прошло между отсчетами[*]Чтобы получить целое число fps - надо 1000 разделить на разность и округлить, верно? Я делю число в 100 раз большее, и потом его пропорционально уменьшаю - получаем два знака после запятой (Ну не умеет флеш округлять с заданной точностью).[*]И теперь главный вопрос - почему я умножаю на _currentframe-2? Потому, что это число есть количество кадров между началом отсчета и этим кадром - fps-то у меня намерился в это количество раз меньший (если содержимое всех тех кадров одинаково). А нам нужно знать не сколько раз в секунду прокручивается весь цикл ролика, а сколько раз в секунду показывается один кадр.
И кстати, то, что над чертой дроби - числитель.[*] Вот и выходит - я считаю совершенно верно (в ваших терминах):

tps-newtime-time; // посчитали tps в миллисекундах
cps1=1000/tps; // перевели в cps (циклы в секунду)
cps2=Math.round(cps1*100)/100; // округлили до двух знаков после запятой
fps=cps2*_totalframes // кадров-то у нас много было

[/list=1]

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

Если же мои изыскания все еще не убедительны - советую взять достаточно медленный компьютер - например, Celeron 300 - и посмотреть, как будет повисать перебор 1000 элементов массива в одном кадре, и как шустро он будет работать в 10 кадрах.

За сим остаюсь.

P.S. Насчет антиалисинга частично соглашусь, но по поводу того, что нужно рисовать больше пикселов? Флеш изначально работает в своих единицах измерения, которые равны 0.1 пиксела при 100% масштаба - этих фликселов обсчитывается не зависящее от размера экрана количество, и лишь потом они рендерятся в растровое изображение. Пример со сменой разрешений был бы схож, если бы при смене компьютеров частота подергиваний менялась, а этого, как я понял из вопроса, не происходит.
P.P.S. - персонально - Forth по сравнению с С рулит... Жаль, что его забыли массы.

[C2Plus]

до момента замера у тебя проходит _currentframe - 1 , а не - 2. Смотри сам: между первым и вторым кадрами совершается один переход, а у тебя получается ноль переходов, что не правильно. Подумай логически - колличество промежутков между произвольными элементами равно колличество элементов - 1.

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