What if Context objects became the interface between the engine and rendering?

[jonathanhogg]

Following on from an idea in #38 of putting references into Context so that @context_funcs can access them, what if the Context was also passed into renderers instead of the current mish-mash of engine, node, references and global names?

Other than possibly just being neater, another key advantage of doing this would be allowing renderers to update the warnings and errors sets. At the moment, there's no good way for renderers to log problems that wouldn't spam the console on each frame, so they tend to just eat errors and forget about them.

[jonathanhogg]

Ways that engine is currently used by renderers:

• physics uses .target_fps and .state
• controller.driver uses .state and .counter, plus calls .has_next_page(), .next_page(), .has_previous_page() and .previous_page()
• controller.push2 uses .counter
• window uses .state and calls .next_page() and .previous_page()

Engine's .state is in the Context already and .target_fps is in the names dictionary. Adding the counter into the context sounds reasonable. The page stuff probably needs abstracting into a better concept of actions (or events?) that would make it easier for controllers to trigger things.

There is probably also an argument for having BeatCounter become part of flitter.model.