хелп!!! скроллинг сцены: растр или вектор FMX v.6 ?

[jab]

прошу прощения у публики ) не знаю - куда писать, поэтому открыл тему и тут и в Новичках...
скроллинг сцены: растр или вектор FMX v.6 ?


сайт. сцена (без текстур) (http://dazdilas.com/test/DazDilas_view.swf) , с массой обектов (в т.ч. очень большой по размерам фон - до 350 Кб в растровом формате), сократить количество обьектов затруднительно, - интерактивны: - освещённость, кнопки..
для уменьшения размера swf все обекты в клипе сделал в кривых. (импорт из Corel и ручная чистка) исходник fla в_архиве_RAR (http://dazdilas.com/test/DazDilas_view.rar)) размер итоговый 800х600 36 кадров.
сцена двигается рывками, комп стандартный может и не потянуть
необходим плавный, по возможности, горизонтальный скролл и масштабирование 2-5 раз определённых фрагментов

вопрос.

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

советуйте, пожалуйста! кто-нибудь имел дело с подобным? возможно, что где-то ответ уже давали? (не нашёл)

очень надеюсь! спасибо!
__________________
word not sparrow

[Ion]

Тут ниче не поделаешь. Замеряй реальную частоту кадров (чтобы определить скорость компа юзера) и в соответствии с результатами измерений меняй качество. У меня (P4 2.4) low почти не тормозило

[unlexx]

сделай сцену 400х300 все равно у тебя все вектор. и маски убери, вместо них сверху положи ректангл с дыркой прямоугольной

[Ion]

нафик размер сцены уменьшать? векторных расчётов от этого не убавится

[Takato]

нафик размер сцены уменьшать? векторных расчётов от этого не убавится

Сравни, сколько проц. юзера будет расчитывать, при просмотре этой сцены - 400 на 300 точек или 800 на 600 например? Есть разница?

Векторы векторами, но при уменьшении сцены тормоза тоже уменьшаются

[Ion]

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

[Takato]

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

Ну это от того, что на флэшке собственно... У меня была где-то флэха - где куча объектов с различной прозрачностью - так при растяжении на весь экран она тормозила раз в 5 больше, чем при 100 на 100 точек например. В данном случае может это и не настолько важно, но всё же

[jab]

ректангл это что? ))

[D-MAN]

Открою страшную тайну. Сам с такой фигней столкнулся. FPS ставь на 1, а onEnterFrame'ы заменяй на setInterval. Как ни странно, моя прога заработала где в 10 раз быстрее. Понимаю, в первого взгляда мистика, но кто знает... =)

[unlexx]

Открою страшную тайну. Сам с такой фигней столкнулся. FPS ставь на 1, а onEnterFrame'ы заменяй на setInterval. Как ни странно, моя прога заработала где в 10 раз быстрее. Понимаю, в первого взгляда мистика, но кто знает... =)
это не мистика это фича :)
из таких фич складывается опыт и мастерство.

[unlexx]

ректангл это что? ))
это обыкновенный залитый шейп в виде прямоугольника

[kost@]

С FPS=1 можно забыть про кадровую анимацию, зато появляется раздолье для программной анимации! Интересно почему setInterval может работать быстрее, чем onEnterFrame?
Попробовал с помощью setInterval() подвигать картинку: особой разницы не почувствовал...

[kost@]

а вообще вопрос о том, стоит ли переходить на растр и будет ли при этом меньше тормозов - вопрос спорный! когда начинаешь шевелить растр (я слышал там про зум и понял, что картинку у тебя вправо/влево будет ходить), тоже появляются тормоза! попробуй на картинку 800х600 налжить эффект вспышки и посмотри чего получится... может немного попробовать оптимизировать векторный рисунок, чтобы просчета меньше было? сгладить где нужно, убрать лишнее?

[iNils]

Открою страшную тайну. Сам с такой фигней столкнулся. FPS ставь на 1, а onEnterFrame'ы заменяй на setInterval. Как ни странно, моя прога заработала где в 10 раз быстрее. Понимаю, в первого взгляда мистика, но кто знает... =)
Проведем два эксперимента. Суть заключается в том, что мы создаем вызов функции 30 раз в секунду с помощью onEnterFrame и с помощью setInterval, а потом получаем среднее время вызова данной функции.

1. Создаем клип с fps 30 и ставим такой код:
y = 10;
this.onEnterFrame = function () {
cx++;
if (cx == y) {
trace ((getTimer () - r) / y);
clearInterval (id);
}
};
r = getTimer ();

2. Создаем клип с fps 1 и ставим другой код:
y = 100;
f = function () {
cx++;
if (cx == y) {
trace ((getTimer () - r) / y);
clearInterval (id);
}
};
r = getTimer ();
id = setInterval (f, 1 / 30);

Теперь сравниваем результаты. У меня получилось в первом случаи в районе 33, а во втором в районе 98.

[Ion]

Надо понимать, что это происходит потому, что enterFrame перерисовывает всю сцену, не зависимо от изменения содержимого, а Interval изменяет только то, что нужно. И никакой мистики

[kost@]

enterFrame перерисовывает всю сцену, не зависимо от изменения содержимого, а Interval изменяет только то, что нужно.
Думаю, что немного не так! onEnterFrame по сути функция. Она не перерисовывает кадр, а всего лишь делает то, что указано в ее теле. Выяснить, почему она работает медленно будет затруднительно, т.к. придется засучив рукава лезть с отладчиком в код самого плейера. Видать контекст вызова onEnterFrame намного больше, чем setInterval! Насколько он больше? Как показывают замеры - раз в 10-ть. Так что пока - это все-таки мистика 80)

[iNils]

Во втором (setInterval) = 3.14
ты fps на 1 не сменил

[kost@]

ты fps на 1 не сменил
Епа-мама, точно... все, ВСЕ дружно забываем про setInterval при FPS=1 80) Но при одинаковых раскладах (одинаковый FPS для setInterval и onEnterFrame) setInterval рулит, похоже!

[iNils]

Епа-мама, точно... все, ВСЕ дружно забываем про setInterval при FPS=1 80) Но при одинаковых раскладах (одинаковый FPS для setInterval и onEnterFrame) setInterval рулит, похоже!
Смотря для чего. onEnterFrame при каждом своем вызове полностью перерисовывает сцену, даже если на ней ничего нет. А setInterval этого не делает.

[E-mail]

в окне ни грамма глюка,при полноэкраном(1024 на 768)лёгкое подёргивание:)
проц-амд 3000+(2.1ггц)
винда - новая не испачканная:)

[Ion]

Думаю, что немного не так! onEnterFrame по сути функция. Она не перерисовывает кадр, а всего лишь делает то, что указано в ее теле. Выяснить, почему она работает медленно будет затруднительно, т.к. придется засучив рукава лезть с отладчиком в код самого плейера. Видать контекст вызова onEnterFrame намного больше, чем setInterval! Насколько он больше? Как показывают замеры - раз в 10-ть. Так что пока - это все-таки мистика 80)я сказал не про onEnterFrame - это функция, а про enterFrame - это событие, которое наступает при перерисовке сцены, а она происходит каждый фрейм. Так что никакой мистики!

[D-MAN]

Да нет, блин, вы не поняли!
У меня в конце каждой функции по setInterval'у стоит updateAfterEvent(). А так как интервалов у меня куча (около 5-6) и инициализируются они в разное время, частота перерисовки (а соответственно нагрузка на проц) получается в несколько раз выше чем при фиксированнои fps, а производительность все равно в 10 раз больше.
В чем прикол?