Queue class (upd v.1.2)



5 Comments

Share




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



5 Comments (+add yours?)

  1. Pavel fljot
    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?

  2. jloa
    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 нужен для управления “головкой” ^_^ чтобы на любом этапе выполениня можно было ей управлять (допустим, пропустить пару айтемов после паузы)

    Спасибо за комент, выкачу апдейт ^_^

  3. Pavel fljot
    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: что-то уведомления о комментах не приходят на почту.. или и не должны?

  4. jloa
    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: хм.. должны, я проде не отключал

  5. jloa
    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 )

Leave a Reply

Spam protection by WP Captcha-Free