We Keep Coding

Throttling events - Perfomance implications of adding and removing event listeners

This isn't a problem I'm having - it's more just a general interest query.
I've just implemented throttling on scroll events on my web app. I've done it in the way all tutorials teach you i.e. inside your function, you block the rest of its execution using some timer controlled variable which makes you wait until the function can be run again.
My question is this: surely in this case, on every scroll event, the function is still being run, it's just that the function is quickly exited so it doesn't take much of a performance hit.
I'm surprised that the standard correct way to throttle events isn't something like:
Add an event listener that runs a function.
When event occurs, run the function, remove the event listener and then set up a timeout to re-add the event listener at a later time.
I presume people far cleverer than me have thought of this and there are good reasons why not to do this.
Is it because it's unnecessarily fiddly? Is it much more processor intensive to add and remove listeners than it is to run empty functions?
I'm just curious. Thanks.

Neither of those is a performance concern. Starting to run a function and then bailing out is very cheap, and so too is adding/removing event listeners. So if you have a situation that can be solved by adding and removing event listeners, and it's easier to under than the other options, feel free to do it.
I can think of a couple reasons why i wouldn't do it though
It's narrow. There are very few problems that can be solved by removing an event listener. Throttling, yes, but even a very similar feature -- debouncing -- can't be done by removing the event listener. (Debouncing means to wait until there's a period of inactivity. So if the function keeps getting called quickly, you'll keep delaying longer. If you remove the event listener, you lose the ability to know that you need to wait longer)
You have to know how to tear down and set up the event listener. For your case that may be fine, but a general-purpose throttle utility (Eg, lodash's throttle function) may have no idea how the function is going to be called. If you use the setTimeout approach instead, then it will work regardless of how it's being called.

EaselJS Perfromance Issue/Frame rate drops

I am working on the project below initially stages animation works fine but after 2nd level the Frame rate drops drastically, below is the link of the game can anyone look into and help me, please!
http://fbapps.ae/mfc/game-demo/
thanks
mustafa

Currently can not get passed level 1. The _animalClicked method shows that the _questions variable is undefined, so you get wrong answers indefinitely.
I would say if you can in fact get past this, and are seeing a frame drop, then it is likely your not properly cleaning up your stage or events.
A few other notes:
Get rid of all the stage.update() calls you have everywhere. Once you call handleComplete, you no longer need to update the stage, because there is a Ticker event which updates the stage constantly. You might want to consider just adding a ticker event initially, rather than waiting for the content to load.
Note that removeEventListener can not be called with no handler argument. Unlike jQuery, this does not mean "remove all events of this type". You are using anonymous handlers, so you will have to hang on to a reference to that function, and pass it to removeEventListener instead. Alternatively, you could use removeAllEventListeners(). Looks like you do that elsewhere.

Should I always removeEventListener?

Say I add a load event to the window like so:
window.addEventListener("load",initialize);
Should I then remove the load event listener from the window after the event is fired? It only fires once, but will it continue to listen after that happens?
It's simple enough to do:
function initialize(event_){
/* Just by adding this line. */
window.removeEventListener("load",initialize);
}
But is that overkill or will that actually benefit the performance of my program? I only ask because the "load" event only fires once, so it would make sense if it just resolved itself. I've never heard of a self resolving listener, though... Any thoughts?
Edit: Also, I'm not concerned specifically with the "load" event, just the general scenario where the listener continues to listen for an event that only fires once.

window.addEventListener('load', initialize, {once: true});

Should I then remove the load event listener from the window after the event is fired?
I've never seen that done, so I don't think there's a real need for it.
It only fires once, but will it continue to listen after that happens?
It is only fired once by the DOM, yes. But it will continue to listen, you could easily trigger a load event manually (see MDN for examples).
But is that overkill or will that actually benefit the performance of my program?
Typically it's overkill, as this doesn't make a huge difference. Of course, it might trigger garbage collection on initialize, which could save a bit of memory (or more, depending on your code structure) and improve performance by making it available to the rest of your app.

Can event listeners be used rather than an interval to check if a variable is a certain value?

Currently, I am using an interval to find out whether the introductary music of my game has finished.
Musictimeout = setInterval(function () {
if (Initialmusic.currentTime > 313) {
Loopingmusic.play();
Loopingmusic = true;
clearInterval(Musictimeout);
}
}, 10);
However, this slows down the gameplay quite consideably until the interval is cleared. Can I use eventlisteners instead of an interval in this situation?

In answer to your main question, there are no generic, built-in event listener that will fire when the value of a variable in javascript changes.
But, if your variable is time related (which a property named currentTime sounds like it might be, then you could probably use a cleverly set setTimeout() to know exactly when to check it's value rather than trying to check every 10ms like you're doing now. We'd have to know more about what exactly you're trying to do and what exactly Initialmusic.currentTime is to know what better to suggest. For example, if you want to know when a particular point in playback is hit, you should be able to register for the start/stop events and just keep your own timer going that should tell you approximately when you get to the desired playback time.
If you are just waiting until the audio completes, then you can just register for the audio event for when it has ended which is the "ended" event. See here for media events.
In addition, for modern browsers only, if you control the creation of Initialmusic.currentTime, then you could define a setter function that would trigger a notification to you any time its value is changed. See this code example: https://gist.github.com/eligrey/384583. I don't know if this type of solution would work for an audio host object (I'm guessing it probably would not). You would have to try it in multiple modern browsers to see.

Executing code after manually firing an event

I'm manually creating and dispatching events to the DOM via createEvent and dispatchEvent...
it seems to work fine.
However, I'm firing multiple events and I need code to execute between them.
If I understand correctly (my background is in server programming), browsers place the event in a queue, which then executes in a background thread.
so if I do work in the foreground I could complete BEFORE the event executes.
Which I think I'm seeing.
.. so my work around is to dispatchEvent... then place a new function via setTimeout(callback,0) ...
the callback in timeout should execute AFTER the event.. correct?
Then I can just make my whole algorithm use callbacks.
do I have this right?