I’ve no idea why this issue was closed - https://github.com/processing/processing4/issues/65 It makes trying to contribute to any development and discussion on Processing development exceedingly frustrating!
I’ve been doing some work on the LWJGL renderer recently. If Processing is ever to fully support an LWJGL renderer, there needs to be a way to run certain tasks on the main (first) thread. What would be thoughts on an API something similar to this in PApplet?
public static MainThreadContext mainThread() {...}
public static void setMainThreadContext(MainThreadContext context) {...}
interface MainThreadContext {
void invokeLater(Runnable task);
boolean isMainThread();
}
Code at the end of main() would have to loop over a task queue. Setting context option is in there for any other language / tooling support, and multiple windows, that need to start sketches in another fashion.
I don’t know enough yet to say anything about it. Could you maybe compare how it is now to how it would be? Do you have more than one possible implementations in mind?
LWJGL has a hard requirement (well, certain OS do) that all UI creation and event handling happen in the first thread of the application - let’s call that the initial thread that runs main(), although it’s a little more complicated than that! JOGL hides this fact from you, which is also why it doesn’t perform as well. Actual OpenGL rendering can be in another thread though, and should be in Processing for a variety of reasons.
The current LWJGL renderer that exists gets around this by running everything inside startThread, but this makes this renderer behave differently to all the others and will break certain things. What’s needed to make this renderer function correctly is to split off the UI tasks from rendering. To do that, an API similar to that suggested needs to exist. For a default implementation, the end of main() would just loop on a queue and run any tasks added to it. However, any embedding (eg. in PraxisLIVE) and potentially other modes would need to be able to set an alternative implementation.
I’m busy working on this, but would ideally do something that can be contributed back.
JOGL hides this fact from you, which is also why it doesn’t perform as well. Actual OpenGL rendering can be in another thread though, and should be in Processing for a variety of reasons.