Форум Flasher.ru - Внутренняя задержка генерации объектов: P166=P2400 xi.net.ru/drawboard.php?npage=1

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript (http://www.flasher.ru/forum/forumdisplay.php?f=5)

Внутренняя задержка генерации объектов: P166=P2400 xi.net.ru/drawboard.php?npage=1

Вот возник такой вопрос: кто-нибудь замечал, что в Flash зачем-то введена задержка генерации объектов?

Возмем простой пример - создадим ролик с пятью-десятью кадрами. В корне создадим объект с именем "cpb". В каждом кадре напишем такую вещь

t1=gettimer();
for (x=1;x<=100;x++) {
duplicateMovieClip (_root.cpb, "p"+npix, i);
setProperty ("p"+npix, _xscale,x);
setProperty ("p"+npix, _yscale,x);
npix++;
}
t2=gettimer();
dt=(t2-t1)+dt;

В первом кадре в самом начале добавим строки

npix=1;
dt=0;

А в последнем кадре выведем значение dt на экран.

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

Теперь запустим этот ролик на слабой машине в стиле P-166КГц и на мощном компьютере P4-2,4ГГц.

Что увидим?

Замеренное время практически совпадает!!

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

Пример можно посмотреть на http://xi.net.ru/drawboard.php?npage=1 Залитие при начальной инициализации листа белым фоном примерно ~0,3 секунды на горизонтальную линию (генерация 64-х объектов "квадратик"). Та же задержка и если просто поменять свойства у нескольких объектов (нажимаем пиктограмки уменьшить/увеличить)

Вопрос! Как обойти это ограничение? Может есть какая недокументированная переменная, или функция, которая регулирует или отключает эту задержку. Или можно еще как-нибудь ускорить ролик?

Re: Внутренняя задержка генерации объектов: P166=P2400 xi.net.ru/drawboard.php?npage=1

Цитата:

Оригинал написал(а) xintrea
Время переключения между кадрами сюда не входит.
....
....
Замеренное время практически совпадает!!
....
как бы вы не старались, получить приличную скорость генерации или изменения свойств объектов не получится
....
....
Может есть какая недокументированная переменная, или функция, которая регулирует или отключает эту задержку.

вы, иван, кажется пивовар? :))

вопрос вызван, скорее всего, незнанием материала :)

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

всё в основном подчиняется фреймрейту.

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

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

представь что было бы, если бы частота кадров напрямую зависела от мощности машины. (нуу... впрочем, она и зависит канеш - но косвенно.)

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

Re: Re: Внутренняя задержка генерации объектов: P166=P2400 xi.net.ru/drawboard.php?npage=1

Цитата:

Оригинал написал(а) Nox Noctis
вы, иван, кажется пивовар? :))
вопрос вызван, скорее всего, незнанием материала :)

Скорее всего наоборот. Копаю глубоко.

Цитата:

программирование во флэше - это отдельная тема, и тут дело вовсе не в языке на основе ецма262, а в том что ориентирован флэш изначально на показ анимации. простой анимации, интерактивной анимации, любой другой анимации - это прежде всего. и ключевые слова тут - frame rate. частота кадров в секунду.
всё в основном подчиняется фреймрейту.

Согласен, но в этом эксперименте фрейм рейт и рядом не лежит.

Цитата:

код, кодторый ты пишешь в кадрах, срабатывает в момент перехода по этим кадрам.

???
Внимательно смотрим на код. В коде замеряется дельта времени между началом и концом КРУЧЕНИЯ ЦИКЛА. Для нескольких кадров эти дельты складываются. Получаем время, потраченное только на кручение цикла во всех кадрах.

Для большего понимания, посмотри что накопали буржуи.
http://www.flash-ripper.com/archives/000148.htm

Цитата:

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

Садитесь, иванов, два! Я замеряю время В ПРЕДЕЛАХ ОДНОГО КАДРА. И складываю это время, замеренное у разных кадров для большей статистики. Линейка кадров здесь - просто для того, чтоб эту статистику и наработать.

... Бред скипнут ...

В ролике http://xi.net.ru/drawboard.php?npage=1 фрейм-рейт установлен на 100 кадров/сек. Появление одной линии - это прощелкивание одного кадра, и время тратится ~0,3 сек. То есть времени на создание кадра уходит больше чем времени, расчитанному по фрейм рейту, ну да пофигу, не в этом дело.

Открываешь этот ролик на P-166, видишь ~0,3 сек делается один кадр.

Открываешь этот ролик на P-2,4ГГц, тоже видишь ~0,3 сек делается один кадр.

Фрейм-рейт тут вообще не причем, если бы по нему считалось, кадры бы прощелкивались за 0,01 сек, ActionScript прерывался б на середине, и пропускались кадры с ActionScript-вставками.

Вопрос остается открытым - как ускорить ролик, поменять системные константы флеш-плейера или еще что. Жду ответа профессионалов.

1) Прикладываю файл. Пример явно показывает, что даже в пределах одного мувика одни и те же действия выполняются разное время, не говоря уж о разных машинах.
2) у буржуев чайников не меньше чем у нас, и имя "Питер Холл" без ссылки на первоисточник мне лично ни о чем не говорит. (старая сказка "а вот в развитых странах...")
3) почитай спецификации формата SWF - они открыто лежат на сайте Macromedia,
вот ссылка
4) Если уж Nox для тебя не авторитет, то кто же? Может John'a сюда позвать?

ЗЫ. Накопали не буржуи, а риперовцы, а это всё-таки разные вещи. Не люблю я буржуев. И когда меня скипают не люблю.

ЗЗЫ Попробуй погонять мой пример с разной загрузкой проца - наглядный показатель :)
вот - картинка:
http://dindin.boom.ru/sample.gif
http://dindin.boom.ru/sample.gif

Цитата:

Для большего понимания, посмотри что накопали буржуи.
http://www.flash-ripper.com/archives/000148.htm

зачем-то решил проверить, получилось с точностью до наоборот:
a = [];
t = getTimer();
for(var i=0; i<100000; i++){
a[i] = 1;//1391 (для шестерки); 1295 (для семерки)
//a.push(1);//1661 ;1521
}
trace(getTimer()-t);
непонятка, однако..

не надо грязи :)

вместо того чтобы защищать своё самолюбие почитай, пожалуйста, то что я написал выше :) м? особенно скипнутый бред.

особо радует вот это высказывание

Цитата:

Согласен, но в этом эксперименте фрейм рейт и рядом не лежит

и вот это хит:

Цитата:

Фрейм-рейт тут вообще не причем, если бы по нему считалось, кадры бы прощелкивались за 0,01 сек, ActionScript прерывался б на середине, и пропускались кадры с ActionScript-вставками.

тут нужно мнение не профессионалов, а психотерапевта.

насчет буржуев - очень жаль, но в той статье написано вообще о другом :) там говорится примерно о том же, о чем есть упоминания в доке по flasm'у - рассказывается о разницах синтаксиса, и чем вызваны различия их работы.

про незнание материала я сказал по двум причинам:

1. потому, что ОСНОВНАЯ специфика флэшовых программ - привязка ВСЕХ действий к фремрейту. (даже действия заданые при помощи setInterval c промежутком времени меньшим чем длительность одного кадра)

2. создание клипов не подходит для бенчмарка вообще. что ты хотел проверить? производительность плагина? тогда взял бы какие-нить математические функции. производительность видяхи очень сильно влияет на скорость работы плеера. и память тоже - тем более что ты выбрал вариент для тестов, в котором необходимо каждый кадр перерисовывать сцену с тысячей объектов. с частотой 100фпс, ага :))

и не надо эти вещи воспринимать как личное оскорбление. ты просил обсудить то что у тебя получилось - я обсуждаю.

пример чистого бенчмарка (тот самый вариант, который "раскопали" "буржуи". (к слову - это было больше двух лет назад :)) :

Код:

_global.total = 0;

_global.count = 0;

this.onEnterFrame = function() {

        _global.count++;

        var s = getTimer();

        for (var x = 0; x<2000; x++) {

                Math.asin(Math.sin(1/Math.sqrt(1+random(100))));

        }

        var e = getTimer();

        _global.total += e-s;

};

this.onMouseDown = function() {

        trace("average : "+total/count+"ms");

};

кроме этого в ролике не должно быть ничего. всего один кадр с этим кодом.
получаем (опять таки - ПРИ ПРОЧИХ РАВНЫХ производительность плагина для данной конфигурации системы) возможно, потребуется сменьшить количество итераций или фреймрейт (дадада :) ), чтобы не выпадала ошибка плеера.

зы: бригада профессионалов уже в пути :))

чего -то бум глюкует сёдня. Вот пиктуре.

Цитата:

Оригинал написал(а) silin
непонятка, однако..

это было два года назад :)
рост это написал почти полтора года назад, а эта тема появилась года два как.

ты небось проверяешь в седьмом плеере? (даже если паблишишь под шестёрку - всё равно плеер переделан уже)