Remove "global" library state

[jamesplease]

This library only supports one instance per page due to the way it is written with global library state. A more idiomatic approach would be to expose a constructor that makes a new MainLoop. For instance,

var mainLoop = new MainLoop(options);

mainLoop.setEnd(cb);

// You can easily make another one
var mainLoopTwo = new MainLoop(options);

Given how well-organized the code is, I think it'd be relatively simple to refactor it to use this system instead.

If this is something you're interested in, let me know and I'd be happy to put together a PR for you to review.

[IceCreamYou]

Yeah, I did that intentionally because having more than one main loop running per thread makes it easy to make mistakes when multiple loops touch shared state. It's called a "main" loop for a reason. 😃

So, I recommend following a pattern like the one used in the demo, where there is one "main" function that calls other functions when work needs to occur. Here is a simple example:

MainLoop.setUpdate(function(delta) {
    updateThingOne(delta);
    updateThingTwo(delta);
    for (var i = 0, l = otherThings.length; i < l; i++) {
        otherThings[i].update(delta);
    }
});

This is more performance-friendly than having multiple loops, and I think being this explicit makes shared state mistakes less likely.

If you need to attach and detach arbitrary functions, you can set up a registry (otherThings in the example above) and call them from within your dispatch function. Or even something like this:

var begins = [],
    draws = [],
    updates = [],
    ends = [];
function MyLoop() {
}
MyLoop.prototype.registerBegin = function(begin) { begins.push(begin); };
MyLoop.prototype.registerDraw = function(draw) { draws.push(draw); };
MyLoop.prototype.registerUpdate = function(update) { updates.push(update); };
MyLoop.prototype.registerEnd = function(end) { ends.push(end); };
MainLoop.setBegin(function(timestamp, frameDelta) {
    for (var i = 0, l = begins.length; i < l; i++) begins[i](timestamp, frameDelta);
});
MainLoop.setUpdate(function(timestep) {
    for (var i = 0, l = updates.length; i < l; i++) updates[i](timestep);
});
MainLoop.setDraw(function(timestep) {
    for (var i = 0, l = draws.length; i < l; i++) draws[i](timestep);
});
MainLoop.setEnd(function(fps, panic) {
    for (var i = 0, l = ends.length; i < l; i++) ends[i](fps, panic);
});

All that said, I would be interested in hearing more about any use cases where making MainLoop instantiable would make the library more convenient to use. For example, perhaps there are legitimate cases where having different physics timestamps would be useful, or where modules with different privileges make sharing a global update callback impractical. If there are compelling use cases here, I think I could be convinced that making MainLoop instantiable would be a good thing.

[IceCreamYou]

I would be interested in hearing more about any use cases where making MainLoop instantiable would make the library more convenient to use.

In the absence of feedback on this, I am closing this issue, but feel free to reopen if there are compelling use cases to add.

[bigsweater]

@IceCreamYou

Hi there,

I may have a use case that merits instantiated MainLoops.

I'm building a web app with a JS library (using Vue). One of my components contains a canvas element, which I've animated using MainLoop.

With Vue, I can add more than one of these elements to a page. (You can see an example of the element in use on Codepen.) When I add new ones to the page (called by dropping a new <starfield> element into the DOM in this case), I want it to be updated and drawn totally separately from any of its starfield siblings (or parents or descendants).

As it is, calling the $vm.start() method (which ultimately calls MainLoop.start()) on one of the instances (where $vm = the individual starfield element I'm targeting) hijacks the MainLoop, if one exists, stopping animation on one of the starfields and starting it on another.

This is a problem for anybody who wishes to use more than one starfield per page. But it also causes issues if, for instance, two starfield elements exist briefly together in memory (as is the case when switching views with Vue). Also, since each component can have its own discrete state, having one global MainLoop feels more difficult to reason about--but that could just be me. In this particular case, it makes more sense to me for each canvas to be its own world, with its own loop.

Does that make sense?

Adding a global manager like you've written above is feasible (and maybe even preferable), but I'd have to create an entirely new Vue component (or use my parent app component) and figure out how to start/stop each instance, if desired, without starting/stopping any of the others.

Obviously having the option one way or the other might be nice, but I love how small this lib is.

[IceCreamYou]

@bigsweater Thanks for the detail. This is the kind of thing I was looking for.

I think animating two separate canvases independently is potentially a good use case for having MainLoop instances, so I'm reopening this issue.

The current model for doing that would be, as you suggested, to have a delegator component that interacts directly with MainLoop and manages when each canvas gets to run its callbacks. This is fine in terms of maintaining timing accuracy and determinism, but it'd be nicer if implementing it wasn't necessary.

[IceCreamYou]

I also thought of another use case: libraries that want to use MainLoop whose users might also use MainLoop. Users would be likely to overwrite the handlers that the library added if they interacted with MainLoop directly.

[bigsweater]

@IceCreamYou Exactly--if I were to distribute my starfield component as it is now, I'd have to pull MainLoop out just in case somebody else is already using it.

That said, the more I think about it, I actually love the idea of having one central manager for animation state and a single rAF loop running--it seems elegant and I imagine it would be performant (depending on the operations in the loops themselves, obviously). Having some sort of standard library like that might be nice for folks like me who don't work with animation often.

I'm using Vuex (analogous to Redux) to manage my app's state--why shouldn't there be a central animation state with an API for dealing with animation loops? It makes a lot of sense.

[jamesplease]

Yup, I agree @bigsweater. I came around after reading @IceCreamYou 's initial response to this issue (then I dropped off the face of the Earth. Sorry 'bout that :) )

I like the idea of this library remaining lightweight, as it is now, and a manager for multiple components to exist as a separate package or in userland.

[IceCreamYou]

Thanks for the feedback. I agree it's important that this library remain slim. Maybe it makes sense to add an optional "callback manager" to the repo that can manage multiple loops. The pattern as a user would be something like:

var myLoop = new MainLoop.Instance();
myLoop.setUpdate(function(timestep) { /* ... */ });
myLoop.start();

When a MainLoop.Instance is instantiated it could quietly register itself with a MainLoop.Manager. If there are no instance loops previously registered, the manager could then set itself up with the core MainLoop to execute its instance loops' callbacks when needed. When #start() is called on an instance, it could just internally ask the manager to make sure the core MainLoop is running and then flip a boolean that the manager would use to determine whether to run its callbacks.

Thoughts?

[jamesplease]

That sounds like a solid API to me, @IceCreamYou .

[bigsweater]

@IceCreamYou I'm still learning JS and don't know too much about architecting a system like this, but that sounds like it would be a winner. Just as easy to use as the current library.

[IceCreamYou]

Good. I'm not sure when I'll be able to get to this, so if anyone feels like providing a PR, that would move things along 😃

[bigsweater]

@IceCreamYou I'm buried but hopefully my site will launch next week! After then I want to take a crack at it.

[iwilliams]

I came here because I thought I had a use case, but as I type up my questions and ideas I find myself questioning the need for multiple loops....

My use case would be to run multiple simulations in a single node process for a multiplayer game, where each "server" would get its own loop. I was originally thinking that each server would need its own loop because you wouldn't want simulation ticks to slow down other people's games, but if all the loops are in the same process the time to process a tick is going to block the other loops if it takes too long anyway. Now what I'm thinking is in each update call I would just loop through all active instances and advance game logic for each one.

I think that my use case is fundamentally similar to @bigsweater, but I find myself coming full circle to the original answer by @IceCreamYou. It seems to me that updating isolated states would be better managed in registered update function which I think is kind of the idea with the most recently proposed "callback manager" solution.

I guess I don't really know where I'm going with this, but I wanted to get these ideas out there since I was considering doing the refactor to support multiple instances.