Busy/Idle events to support code benchmarking

[bhousel]

@vanreece has been doing an investigation into code benchmarking and we could really use some more events sprinkled around the various parts of the RapiD code that perform background work (data fetching, etc), so that we're able to run the performance benchmarks when the system is in a quiesced state. (https://github.com/mapbox/mapbox-gl-js/issues/1715 comes to mind).

My plan is to add events like this anywhere that the system is doing background work that might affect performance, or where we might want to show a spinner or something.

• .on('busy') - component started doing something in the background (fetching tiles, etc)
• .on('idle') - component is done whatever it was doing

then context will also listen to these and keep a count going to expose a main event like:

• context.on('busy') - at least one component somewhere is busy
• context.on('idle') - all components are done their work

Will write this in a way that the events will always be matched up, e.g. fire 1 single busy , then later 1 single idle.

[bhousel]

I've added the events to the Esri and FBML services and it's pretty cool - here is with some console logging:

Also you can bind handlers to context and do this:

I'm thinking a bit more about how we might want to use these events, and considering:

• should the events come with a payload of data?
• another event like .on('work') dispatched sometimes to say how it's going / what it's doing?

Just tossing out ideas - don't want to overthink it and we can change it later.

[vanreece]

Awesome. Looking good! I think eventually we may want a more robust system of information that can happen, I could totally imagine some sort of x/y tiles loaded or something eventually happening, but we can always add that later. Thanks Bryan!