Queue class (upd v.1.2)
as3, queue, stack
Oct 02code5 Comments
Sometimes you need to do a bunch of similar tasks at once (create similar display objects, render stuff, reindex pools etc), but often this may be a pain due to performance limits (which may result in poor user experience) and that’s where the queue pattern comes to the rescue. I’ve wrote a simple thought useful util for that purpose.
Play with the demo below (a simple IQueueItem implementation) or download the source (com.chargedweb.queue.*)
UPDATE: v.1.2 update + docs updated
Oct 03, 2011 @ 03:19:07
Looks very handy. But why is delay in milliseconds? FP deals with frames anyway.
Ну и так всякие поверхностные вопросы:
1. Queue#(item:IQueueItem):void
а не проверять ли на наличие
2. Queue#addItemAt(item:IQueueItem, index:int):void
а почему не uint — так не нужно было бы проверять if(index < 0
ну и опять таки проверка на наличие?
Queue#removeItemAt(index:int):Boolean
3. Queue#removeItem(item:IQueueItem):Boolean
цикл быстрее indexOf?
4. Смысл геттеров/сеттеров для items, position?
Oct 03, 2011 @ 08:43:08
>But why is delay in milliseconds?
as the native flash api (timers) usually uses milliseconds (enterframe execution time depends on rendering, whether timers don’t)
> Queue#(item:IQueueItem):void – why not check for item existence?
hm… nice suggestion, put in the todo
UPD: nope, as it depends on the task, you might want to add same item at different indexes. it’s better to implement the contains() method, so that you check for item existence if needed
> Queue#addItemAt(item:IQueueItem, index:int):void / Queue#removeItemAt(index:int):Boolean – why not use uint instead of int type
int is faster
> Queue#removeItem(item:IQueueItem):Boolean – is the for loop faster than indexOf?
yeap, indexOf is slower
> What’s the point in items, position setter/getters?
items – so that you could get the entire stack (just in case)
position – so that you could manage to skip items while running the queue. In the demo above follow these steps: run the queue, pause at any desired index (10 for instance), after that change the current head position to 15 (that would skip the items from 10-14) and press the start button.
Comments are much appreciated btw
——–
1. Queue#(item:IQueueItem):void – а не проверять ли на наличие
> можно, добавлю.
> UPD: неа, я тут подумал, и понял, что это зависит от задачи, возможно ты захочешь пихнуть в стек один и тот де айтем на разных индексах (всякое бывает). Лучше добавить метода contains(), как раз на тот случай, когда необходима уникальность айтметов в стеке.
2. Queue#addItemAt(item:IQueueItem, index:int):void – а почему не uint?
> int шустрее, проверку добавлю, да.
3. Queue#removeItem(item:IQueueItem):Boolean – цикл быстрее indexOf?
> цикл шустрее
4. Смысл геттеров/сеттеров для items, position?
> чтобы можно было получить доступ к стеку для, скажем назначения другой очереди (ну, так, на всякий случай). position нужен для управления “головкой” ^_^ чтобы на любом этапе выполениня можно было ей управлять (допустим, пропустить пару айтемов после паузы)
Спасибо за комент, выкачу апдейт ^_^
Oct 07, 2011 @ 05:51:14
0. The FPS drop happens when FP fails to complete frame code during planned frame execution time. The crashing happens when frame execution time is longer then N ms. So I see frame-based delays are more precise and make more sense for development. That’s why I personally expect delay to be in frames rather then seconds. In other words: seconds-based delay does not guarantee your code will be distributed on separate frames:
var frameCounter:uint = 0;
addEventListener(Event.ENTER_FRAME, onEnterFrame);
var timer:Timer = new Timer(5);
timer.addEventListener(TimerEvent.TIMER, onTimer);
timer.start();
function onEnterFrame(event:Event):void
{
trace(“frame “, ++frameCounter);
}
function onTimer(event:TimerEvent):void
{
trace(“timer”);
}
output:
frame 1
timer
frame 2
timer
frame 3
timer
timer
timer
timer
frame 4
timer
timer
timer
timer
timer
frame 5
timer
timer
timer
timer
timer
frame 6
timer
timer
timer
frame 7
4. I mean why getter/setter? In that code it’s totally equal to public var.
PS: что-то уведомления о комментах не приходят на почту.. или и не должны?
Oct 07, 2011 @ 06:55:14
“The FPS drop happens when FP fails to complete frame code during planned frame execution time.”
>> yeap, that’s the only case and it’s almost every time related to display objects operations, especially in game dev. I guess i’ll make a two-way implementation time-base or frame-based of the delays.
“I mean why getter/setter? In that code it’s totally equal to public var.”
>> habit ^_^
ps: хм.. должны, я проде не отключал
Oct 10, 2011 @ 10:39:44
updated the class to 1.2, now you can specify the delay time (whether to use milliseconds or frames @see Queue->useFrames )