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]

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

[Dendroid]

fps=(_currentframe-2)*Math.round(100000/(newtime-time))/100;
:D :D :D
Тебе в AMD надо работать будешь для них тесты придумывать, чтобы они Intel и дальше обгоняли :D

Начинающим упражнение: что надо исправить, чтобы получить правильные результаты: где-то выигрыш процентов 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.

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

[Dendroid]

Ну все, я долго терпал, но щас будет лекция.... :cool:

Разберемся с самого начала:
1. Вариант с 10 вызовами по 100 итераций цикла. Состоит из двенадцати фреймов. Первый и последний фрейм - несколько простых присвоений и инициализаций - выполняются за <1мс, остальные десять фреймов, соответственно, содержат вызов функции calc02 и выполняются за 10-12 мс на селероне-500 (время зависит примерно линейно от частоты проца и сути дела не меняет...)
Как известно, флэш работает очень просто: если время затраченное на выполнение всех операций во фрейме (скрипты и перерисовка экрана) меньше времени отведенного на фрейм, то флэш делает паузу до окончания зарезервированного времени (у нас fps мувика - 100, поэтому время на фрейм = 1000мс / 100 = 10мс). Значит, в первом случае, мы видим практически идеальное распределение: десять фреймов по 10-12 мс - полностью расходуют отведенное на фрейм время, есть еще правда два фрейма, которые используют <1 мс времени, поэтому в первом и последнем фрейме будет неиспользуемая пауза в 9 мс как результат контроля со стороны самого флэш-плеера (может стоило хоть как-нибудь избавиться от этих накладных расходов? - точность измерения резко падает - за такое составления теста меня бы еще на втором курсе универа бы препод по выч. методам убил :))
Получили распределение времени по фреймам:
10+11+11+11+11+11+11+11+11+11+11+10=130мс
2. Вариант с одним вызовом: второй фрейм с вызовом функции calc4 (1000 итераций цикла) выполняется за 100 мс (чуда не произошло, одна функция выполняется немного быстрее, чем десять с тем же количеством итераций, небольшое ускорение - за счет уменьшения накладных расходов, уменьшение количество инициализаций), получаем распределение:
10+100+10=120мс
Дальше у тебя идет софизм (это ничего, что я на "ты"? :) я просто думаю, что все флэшеры - братья навек :)): ты умножаешь одну из примерно равных величин на величину в 10 раз большую: (_currentframe-2) - вот и получаешьвремя обработки различается в десять раз
Какое время? Время вон, сверху написано: 130 и 120 мс соответственно....
А падение среднего fps во втором случае естественно, ведь у тебя во втором мувике в 4 раза меньше фреймов - значит, будь рейт одинаковый (на очень быстрых машинах, где тысяча итераций занимают < 10 мс) вызов функции с 1000 итерациями должен происходить в 4 раза чаще, чем вызовы всех 10 функций в первом примере. Сделай во втором мувике тоже 12 фреймов и перетащи вычисление производительности из третьего фрейма в 12-й - тогда твоя формула начнет получать более-менее правдивые результаты.

Смольный, возмешь меня в школу преподавателем? :D :D
У меня и опыт преподавания имеется..... :D

Насчет антиалайзинга и фликселов: я имел ввиду виндовые пикселы окна, C2Plus прав, самые медленные - это виндовые GUI-шные операции вывода изображения, поэтому имеем большее окна - имеем больше виндовых пикселов - винда больше тратит времени на вывод изображения.

[Dendroid]

По твоей формуле можно получить как бы падение производительности во сколько угодно раз.
Для получения, скажем, в 100 раз:
первый мувик делаем состоящим из 102 фреймов (100 фреймов с вызовом по 100 итераций), а второй - также три фрейма, с вызовом во втором функции с 10000 итерациями - время естественно опять останеться примерно равное (еще немного более в пользу одного вызова), зато _currentframe в последнем фрейме станет в первом случае 100, а во втором так и останется - 1. Умножаем, ужасаемся......
Для получения падения с нужным количеством нулей - добавлять еще фреймов.....

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

[Nox Noctis]

оо дааа... я долго въезжал ... :)) кто-то перебрал пломбира с маком и коноплей ... :))
Оригинал написал(а) Dendroid
насчет вот этого тоже не понял:
теперь вроде все понятно...

уж не знаю что именно подразумевалось под "классическим программированием" - но тест как раз сделан с точки зрения... ээ... "классического"... :)
то есть без учета того, что во флэше ВСЕ подчиняется фреймрейту.
(ну, да, он очень непостоянен и может скакать в зависимости от того, что происходит на сцене - но главное, что БЫСТРЕЕ фпс ничего не произойдет)
в этом весь и клин...

если следовать логике исходного теста ilya_cat,
то надо было сделать ВСЕ ДЕСЯТЬ вызовов в ОДНОМ кадре. и сравнить время.
а не расписывать вызовы по кадрам.

то есть в первом варианте вызвать сто раз за один присест,
а во втором - сто раз за десять присестов,
но все равно в ОДНОМ кадре.
и сравнить.
только тогда это уже тест на производительность Flash Virtual Machine а не на реальный фпс мувика...


реальный фпс измерять можно одним простым способом -
засекаем
start = getTimer(),
потом куда-нить пишем
onEnterFrame = function () {
fps = ++counter/(getTimer()-start)*1000;
}
дешево и сердито...
только все равно из-за издержек при самом обсчете фреймрейта набегает солидная статистическая неточность...