Feature: make ofGetCurrentRenderer work across multiple threads.

If you have an app with multiple GL contexts each in its own thread - all the current OF calls fight each other as the current renderer can change back and forth between the threads.

I saw this recently when trying to get the threaded Kinect V2 GPU decoding stable in @hanasaan gpu branch https://github.com/hanasaan/ofxKinectV2/tree/of_gpu_dev

Basically the multiple GL contexts are totally fine as each are in their own thread. Pure GL calls work fine. But calls to OF renderer related functions can cause really strange issues ( viewports inverting on the main thread, strange graphics glitches etc ). This is because a call in the second thread mixes its OF renderer commands in with the first thread.

Thinking about it I thought that it would be impossible to keep our current API and support multiple threaded contexts.

ie: calls like ofPushMatrix(); ofPopMatrix(); etc.

However I think it could be possible that ofGetCurrentRenderer() would be able to register renderers based on the thread they are running in. So a call to ofGetCurrentRenderer()->draw(video, 0, 0, 320, 240); Could internally check the thread id and if there was a renderer registered for that thread it would use that renderer.

This would allow the renderer's to operate completely separately while still supporting the global functions that we have in our API. If I understand it right we could make this fix without changing or breaking any of our current API.

Curious what people's thoughts are on this.

Start with the ofGetCurrentRenderer() entry point and the renderer-related calls described in the issue, especially draw(video, 0, 0, 320, 240) and the global matrix functions. Investigate how renderer selection behaves across separate GL contexts and threads; done means independent per-thread renderer behavior without changing the current API.