"The model for interpretation of GL commands is client-server..."

[arielm]

Quoted from the OpenGL 1.1 specs:

The model for interpretation of GL commands is client-server. That is, a program (the client) issues commands, and these commands are interpreted and processed by the GL (the server). The server may or may not operate on the same computer as the client. In this sense, the GL is 'network-transparent.'' A server may maintain a number of GL contexts, each of which is an encapsulation of current GL state. A client may choose to connect to any one of these contexts. Issuing GL commands when the program is not connected to a context results in undefined behavior.

A few years later, it seems that this approach is still relevant, e.g, in projects like Wayland.

In short: Wayland is based on EGL / GLES2 and it handles input as well (it is one of the supported platforms in recent GLFW versions...)

Open question: how to put all all this wisdom to use with Emscripten and WebGL?

[arielm]

A recap of the state-of-the-art, as I understand it:

1) The async command-queue approach:

• Today: WebGL in Web Workers, Today – and Faster than Expected!
• Future: WebVulkan and multithreaded command queue assembly
• Should help:
  • SharedArrayBuffer support in Firefox nightlies
  • New experimental support for pthreads in Emscripten

2) The shared frame-buffer approach:

• Big-picture: the Wayland architecture
• Future:
  • The OffscreenCanvas proposal
  • Some context: Canvas in workers
• Should help:
  • Some recent Mozilla patches?