Expose the main thread.

[azul3d-bot]

Issue by slimsag
Saturday Nov 08, 2014 at 06:05 GMT
Originally opened as azul3d-legacy/gfx#39

---

There are certain situations where one needs explicit ownership of the main loop. A good example of this is Cocoa API's which must be executed on strictly the main thread, inherently any GUI libraries that operate on OS X also have this requirement.

The goal is to expose control of the main loop to the user of the package, if they so desire.

I propose exposing a channel window.MainLoopChan over which arbitrary functions (which MUST be ran on the main thread) will be sent by running windows.

This would allow for a swift communication with the window package on-demand (i.e. when the window package doesn't need to execute functions, you don't execute any, in contrast to busy-waiting glfwPollEvents and things).

At least one problematic side effect of this is that we can no longer utilize go.mobile/app because it steals the main loop entirely.

See azul3d-legacy/issues#29 for previous discussion.

[azul3d-bot]

Comment by slimsag
Saturday Nov 08, 2014 at 06:07 GMT

---

Something I want to clarify: This would expose the main thread but would not offer any communication with the OpenGL render loop.

[azul3d-bot]

Comment by slimsag
Sunday Nov 16, 2014 at 21:19 GMT

---

See also discussion in #40

[slimsag]

Fixed/merged as part of #1