![]() |
Вопрос: удаление всех Child из родительского мувика.
Перевожу прогу AS2->AS3.
Проблема: Есть top:MovieClip - родительский. В нем создаю через new MovieClip и addChild еще мувики (программно создаю). Есть кнопка очистки родительского мувика. Алгоритм чистки следующий: function clearTop(){ for(var i:Number = 1; i<=top.numChildren; i++){ if(top.getChildAt(i)){ top.removeChildAt(i); } } } Алгоритм работает один раз - чистит содержимое top, а на второй раз - ругается что нет нифига - ругается 2006 ошибкой, типа нет мувика с таким индексом. Хотя проверку я поставил. Как сделать корректную проверку на существование Child? Замена top.getChildAt(i) на Boolean(top.getChildAt(i)) - ничего не дала |
Ошибки:
1. индексы детей начинаются с 0. 2. Код:
if(top.getChildAt(i)){3. Код:
for(var i:Number = 1; i<=top.numChildren; i++){...вот ваш алгаритм: Код:
start. 1. 2. 3. |
Обалдеть! А как тогда правильно удалить всех детей родительского мува?
|
или так:
Код:
while(this.numChildern > 0) this.removeChildAt(0);Код:
for(var i : int = 0; i < this.numChildern; i++) this.removeChildAt(0);Код:
for(var i : int = this.numChildern-1; i >= 0 ; i--) this.removeChildAt(this.numChildern-1); |
или так:
Код:
var num:int = super.numChildren; |
Парни! Идеально! Спасибо!!
Недопетривал стековость контейнера. Теперь вообще многое прояснилось))) |
Маленькая лепта от меня:
Код:
while (container.numChildren) |
ну если на то пошло то numChildren тоже жрёт ресурсы.
|
Ну я не спорю, только почему-то мне кажется, что numChildren кэшируется при изменении количества детей и возвращается по требованию, а не пересчитывается каждый раз при обращении к нему. ;-)
|
Узнайте кол-во детей один раз...и удаляйте относительно него + лучше удалать, начиная с верхних, чтоб не менять индексы слоев при удалении.
|
Цитата:
|
Цитата:
Код:
var num:uint = container.numChildren; |
-- работает гараздо медлее чем -=. и теперь глянь на код, который я написал
|
Цитата:
Обратный инкремент с автоматическим приведением типов: Код:
var t:int = getTimer();Код:
var t:int = getTimer(); |
и что? это доказывает мою правоту.
|
Почему? Наоборот: предложенный мной вариант выполнился за 181 миллисекунду, а предложенный тобой - за 235.
|
Azim, отредактируйте свой первый пост и оформите код тегами [code][/code].
з.Ы. Код:
var t:int = getTimer(); |
Выносим инициализацию переменной i до таймера, и видим немного другие результаты =)
Код:
var i:uint; |
BlooDHounD, Бармалей: вы потратили машинного времени на обсуждение этой ерунды больше, чем все флэшеры мира сэкономят на таких итерациях за последующие 50 лет.
|
Цитата:
|
Цитата:
//200 //54 соответственно Еще не совсем понял из каких соображений переменная i типа uint, а не int. Для int у меня выдало: //66 //48 |
Цитата:
Код:
trace (flash.system.Capabilities.version); |
WIN 9,0,115,0
|
Цитата:
[img]http://img232.**************/img232/7006/speeded9.png[/img] Код:
txt.text = Capabilities.version+"\n"; |
Я заметил только, что имеет значение очередность работы циклов. Если поменять блоки циклов местами, то вот что получится. Хотя, если ничего не трогать, то будет вот так. Предыдущие указанные мною значения были получены при тестировании в FlashDevelop на рабочем компе.
|
to __etc
Так int же не обязывает использовать отрицательные значения. Просто тут обсуждение перешло в область оптимизации, а то что int шустрее чем uint вроде как давно известно. По-этому и не понял зачем оно тут, тем более, что numChildren типа int. Цитата:
|
В смысле ничего не менять? А как же тогда показать, что первый цикл выполняется медленнее, чем идущий за ним? =)
|
коряво выразился ))
в смысле ничего не менять, и несколько раз запустить и посмотреть какие значения будут выдаваться. Может там +-20 разброс )). |
Цитата:
У меня тенденция не меняется, хоть в разных местах циклы поставь, декремент -=1 всегда быстрее --. Причем разница ощутимая: [img]http://img216.**************/img216/1510/speedum8.png[/img] |
Давайте устроим массовую проверку. Вот swf-ка, скомпилированная при помощи Flex 3 SDK. А вот содержимого ее главного класса:
Код:
packageКод:
package Цитата:
|
Значит это особенности компилятора CS3. Вне зависимости от этого, лучше использовать декремент с числом, дабы не получать неожиданных результатов.
|
Повод для размышлений:
Код:
package { |
WIN 9,0,115,0
39 45 result такой |
незабывайте что:
Код:
... |
Цитата:
http://etcs.ru/blog/as3/slow_increment_ii/ |
а причем тут это?
я говорю, что ты сразу считаешь циклы.. потому и нагрузка больше на последний цикл. Проверка циклов поотдельности даст более точный результат, что лучше. Да математика вся не во флеше, а в процессоре. |
Предполагаю, что инкремент/декремент поля через ++ и -- превращается примерно в такой байткод:
1. взять поле i 2. увеличить 3. записать в поле i 4. взять поле i И вот этот самый четвёртый пункт всё и портит. |
о, госпади! спаси души этих еретиков!
|
Вот так выглядит i++, если i - это поле:
Код:
findpropstrict iКод:
findproperty i |
Цитата:
В общем, все всё выяснили, я думаю, вопросов больше возникать не должно. з.Ы. Походу я отстал от жизни, раз пользуюсь собственным декомпилятором и не знаю о уже существующих :( |
| Часовой пояс GMT +4, время: 22:25. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.