Разбиение ресурсоёмких операций по кадрам

[totto]

ничего не понял...
Умножаем на время, при котором не просядет фпс, и получаем время, при котором не просядет фпс. Это как?
Может имелось в виду что надо задать какое-то разумное время, а затем в каждом кадре если fpsRatio < 1, то время уменьшать, а если fpsRatio > 1, то увеличивать.
Только > 1 быть никак не может, так как targetFps вкомпиливается в swf и чаще рендер производиться не будет. Так что в итоге операции будут работать по пиковой загрузке (обеспеченной не только флешом, но и другими программами). Хотя конечно можно и при fpsRatio = 1 увеличивать... Тогда флешка по идее будет всегда работать при слегка присевшем фпс, но зато не будет больших проседаний.

[i.o.]

Умножаем на время, при котором не просядет фпс, и получаем время, при котором не просядет фпс. Это как?

Прочитайте внимательнее.

Объясняю последний раз:
В самом начале у нас есть тормозная функция megaCalculation( timeLimit:uint ), которая принимает время в мс, которое она должна отпахать, и не более.
В самом начале у нас есть targetFps = 30
В самом начале у нас есть расчетное_время, скажем 33мс на кадр (из расчета 1000мс / 30фпс)
У нас есть счетчик фпс
Каждый кадр мы узнаем отношение fpsRatio как currentFps / targetFps
И после этого вызываем мегаТормозную функцию как megaCalculation( fpsRatio * расчетное_время )

расчетное_время - "Умножаем на время, при котором не просядет фпс"
fpsRatio - "Умножаем"
fpsRatio * расчетное_время - "и получаем время, при котором не просядет фпс"

Еще вопросы есть?

[gloomyBrain]

@totto
Есть такое событие Event.EXIT_FRAME - так что длительность текущего кадра можно считать по нему. Необходимую длительность кадра можно записать в констатнту. Соответственно, сравнить будет просто.
Далее, в обработчике ENTER_FRAME запоминаем, сколько собираемся сделать операций. Делаем операции. В EXIT_FRAME смотрим, не просел ли fps. Если просел - уменьшаем число операций для следующего ENTER_FRAME

[i.o.]

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

[gloomyBrain]

Да я больше к тому, что как-то странно это - регистрировать несколько ENTER_FRAME с разными приоритетами

[i.o.]

Сообщение от gloomyBrain

Да я больше к тому, что как-то странно это - регистрировать несколько ENTER_FRAME с разными приоритетами

ну это да, правильно )

[totto]

i.o.
Спасибо, теперь наконец-то понятно что Вы имели в виду.
Я думаю, что воспользуюсь таким подходом. Хотя мне кажется ориентироваться на жёстко задаваемую константу всё же не стоит, а лучше изменять это самое расчётное время в зависимости от проседания/не проседания fps.
В общем ещё раз спасибо.
gloomyBrain
EXIT_FRAME срабатывает сразу после ENTER_FRAME и до RENDER, так что разница между подпиской на ENTER_FRAME с низшим приоритетом и подпиской на EXIT_FRAME с практической точки зрения нет. Только разве что с точки зрения красоты кода.

[i.o.]

Сообщение от totto

Хотя мне кажется ориентироваться на жёстко задаваемую константу всё же не стоит, а лучше изменять это самое расчётное время в зависимости от проседания/не проседания fps.

А вот это не советую делать. Это уже выполняется с помощью fpsRatio * расчетное_время.
Единственное что могу подсказать, так это высчитывать при запуске приложения максимально приемлимое время выполнения, при котором фпс чуть не проседает. Т.е высчитывать в самом начале расчетное_время. Потому что у всех компы разные, и если даже скрипт будет выполнятся ровно столько времени сколько ему отведете, то графика может не успевать отрисовываться за оставшееся время.
Поэтому советую запускать что-то вроде теста производительности на старте.

[totto]

Я имел в виду, что вместо вызова

megaCalculation(fpsRatio*time);

где time - это и есть то самое расчётное время
буду делать как-то так:

if (fpsRatio < FPS_RATIO_MIN)
      time -= 1;
else if (fpsRatio > FPS_RATIO_MAX)
      time += 1;
megaCalculation(time);

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

[expl]

2 expl:
Отлично, ещё бы где-нибудь этот конвейер найти, так как все ссылки в поиске по этому форуму, да и просто в поисковике ведут на potapenko.com, где сейчас нет ничего, кроме предложения стать обладателем этого домена.

Вот это да Сайт Потапенко снесен, а в сети нет больше кода этого конвеера,
хотя что-то похожее народ делает (http://sheremetov.com/flash/flexunit-async/)
Забейте тогда, чтож поделаешь.