can I request a Texture constructor which is usable by job threads? Currently the construction leads to gl calls which segfaults for not having an OpenGL context. I have made a small work around by moving the glBufferData() call to be done inside the first Texture::draw() call of a particular texture. which maybe the best way of implementing this feature. We should also have some kind of check that Texture::draw() is called using the main thread.

Maybe we should move all program logic (including the main loop) outside Thread #0 (the thread that owns the OpenGL context and provides input), and have all other threads make synchronous calls into Thread #0?

My plan was to create a queue structure for all tasks to be rendered. Things to be drawn (textures, texts, geometries, whatever) would be added/registered to a queue and the renderer, when it's ready for the next call, fetches all those instructions, reorders them and then renders them to the framebuffer.

The registering/adding can be done from any thread, the renderer will either fetch the instructions itself or the instructions are converted/processed upon enqueuing, i haven't decided on that yet.

Basically all other subsystems will get backend-independent handles for all the render calls, so opengl or vulcan or maybe html5 someday can do the actual rendering then.

The thread-independent texture (TextureData in renderer/texture.h) should now be there i think. You can fill it with data anywhere and have to register it at the renderer instance to actually create the internal opengl handles.

https://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/

Continued in #850 :)