Такой вот странный вопрос

[MagicMax]

Люди, кто нидь, окромя меня замечал, что Flash Player 6 работает медленнее? Или ето только у меня такой баг? Такое вчепятление, что 6-ка хуже (медленнее) рендерит (прорисовывает) векторную графику и при наличии на сцене кучи (500-600) мелких объектов начинает безбожно тупить....

[Иван Старков]

По субъективным ощущениям,
осталось так же, и там и там Proc load 100%

[MagicMax]

Я к чему ету тему то завел: при Player'e V5 мое приложение, активно использующее XML (400-500 элементов, 30-40 КБ), многократные поиск по дереву XML в цикле и выводящее на сцену большое количество маленьких элементов работает хоть с небольшими тормозами но приемлемо, в 6-ке же оно умирает... Поетому и провожу соцопрос, может у кого такая же бага.

И есче вопрос - как принудительно заставить (или запретить ставить 6-й Player) 5-ю версию Player'a. Если так
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0"
, то все равно спрашивает запрос на инсталляцию 6-ки, а только потом 5-ки.

[Иван Старков]

И люди к тебе потянуться,
я вот как делаю сгенерил в пятерке html, и тег object всегда беру из него, заменяю там ссылку на swf и тп., вообщем
тогда не спрашивает загрузить 6.

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

Я вот думаю могет написать для flash типа SAX парсер (на встечу -завершение тега генерится событие), хотя не знаю,
из xmlSocket можно читать что нить кроме xml?
если нет то такой парсер не нужен.

Пишется быстро, а будут ли тормоза не известно.

[MagicMax]

Ха, я то как раз и генерил HTML в 5-ке, ето строка из него как раз. Но Макромедия решила что она умнее всех, и решила выпендриться, подсовывая новый тупящий плагин.

По поводу тупинга с XML: мне кажется, тупит не XML а то, как Flash 6 Player работает с циклами и графикой. Я тоже читал их восторженные отзывы, очень ждал выхода 6-ки, чтоб лишиться небольшой тормознутости в моем приложении, а что получил? В 6-ке получил умирание компа и вывод предупреждения о том что скрипт выполняется медленно... В 5-ке же все работает... Сырая мне кажется пока что версия MX, так что я пока буду писать для 5-й версии плагина. Надеюсь они ето пофиксят.

Пример: я проверял как быстро происходит parse:
Version 5: 33 min. 5 sec. 511 millisec. - 33:7:314 = ну где то 2 сек.
Version 6: 17:7:203 - 17:7:344 - улучшение налицо
XML файл где то 40 Кб, 484 элемента с аттрибутами. Я долго ругался с ними по поводу моей проблемы, говорил типа мы за что бабки платим (короче разводил их всячески на базар )в News'ах в конце концов послал свои замечания в их Support Center.

XMLSocet не пробовал, ничего сказать не могу, но мне кажется что можно посылать не только XML

[Stellerex]

2Иван Старков:
В шестерке используется Expat. В-принципе, понятно почему: он изначально был ориентирован на разбор потокового XML.

2MagicMax:
По моим тестам, по сравнению с пятеркой скорость разбора выросла раза в 2-3 раза, так что, скорее всего, неоптимален твой алгоритм пробега по дереву. У XMLSocket в шестерке есть два события - onData и onXML. Вешай обработчик на первое - параметром придет не распарсенный объект, а обычная строка.

[MagicMax]

2Stellerex: Как то странно тогда получается, в 5-ке алгоритм оптимален, в 6-ке - нет. Зачем тогда делать след. версию плагина, кот. полностью несовместима с предидущей? Про разбор - базару нет, как и показал мой тест, скорость разборки выросла, а вот остальное? Скорость прохождения по дереву в цикле я не измерял, нет времени к сожалению, и подозреваю что в этом случае скорость снизилась. Второй проблемой, как мне кажется, является неоптимизированный пока что (надеюсь ето пофиксят) алгоритм прорисовки большого количества мелких объектов на сцене (возможно этот пункт и является ключевым в вопросе о тупинге в моем приложении)

[Иван Старков]

Ну все равно ничо у макромедиа получилось,
mp3 играть может, видео играть и тп.
И все это в нескольких сотнях килобайт кода!!!
Еще и анимацию делает :-)
С трудом понимаю как у них это получается.
Так что все неудобства можно простить.

А по поводу разбора, в обычном JavaScript,
если требуется хранить к примеру 10000 каких либо значений,
к примеру в цикле
for(i=0;i<100000;i++)
{
a[i].p1="sad";
a[i].p2="sad2";
a[i].p3="sad3";
}
данный код серьезно подвешивает JScript
вобщем серьезные там возникают расходы при присваивании и инициализации.


самый прикол что если хранить значения в xmlDoc=new
ActiveXObject("MSXML.Document")

то есть в цикле добавлять appendChild("elem");
а потом setAttribute("p1","sad") и тп. работает быстрее.

Это я к чему все, у Макромедиа JavaScript скорее всего похуже чем Microsoft, вот и подтормаживает при инициализации и определении большого числа объектов.
JavaScript при парсенье xmlDoc, MS Xml парсером, тоже подляжет но на кол-ве узлов больше чем 10000, с учетом что их надо положит в массив или куда еще.

[Stellerex]

Ну, собственно говоря, ничего странного тут нет - Flash, как говорится стал truly object-oriented, отсюда и тормоза. Я тебя, не удивлю наверное - достаточно известный факт, что для алгоритмов, критических по производительности, вообще рекомендуется использовать нотацию четвертого флэша. Например,

myMC.gotoAndStop() работает в 25!!! раз медленнее, чем tellTarget("myMC") gotoAndStop().

[MagicMax]

Во блин засада... Похоже я буду переделывать так, что все основные операции поиска по дереву перебором, склеивания 2-х XML-файлов и пр. будет выполнять как раз этот xmlDoc=new ActiveXObject("MSXML.Document") с пом. JScript'a , тем более что я и так его использую на страничке в флешем.

Да ... Жаль, помаленьку разочаровываюсь в Флеше, как в инструменте создания сурьезных веб-приложений. Блин, Макромедия, неужели непонятно, что если б вы подоптимизировали немного работу плагина, то им бы больше пользовались для создания нормальных веб-приложений, чем для всяких игрушек... Сделали б Flash MX такой своеобразной заменой Java