Hello,
I’m Tianshuai pursuing Software Engineering from Harbin Institute of Technology, China. I hope to work on New OpenGL Renderer during GSOC 2019. But I encountered some problems with the project.
I found that the project imported processing.core, but it’s not in lib. I found it in processing, so if I want to run the test code in LWJGL, do I need to fork and clone the code in processing as well?
What kind of 2D and 3D renderers do we have to make? What should it looks like? What functions should it provide? Is there a template that can be referenced? I feel a little confused. Forgive me for being the first time with 2D and 3D renderers.
@tianshuai – I can’t answer the project questions, but I can tell you that the current OpenGL 2D and 3D renderers are P2D and P3D, and they are extensively documented in the Processing reference, tutorials, and Java API.
The renderers should be P2D and P3D, for 2D and 3D rendering respectively. They are already implemented in the code of processing-lwjgl, as the PGraphicsLWJGL2D PGraphicsLWJGL3D classes. Both are subclasses of PGraphicsLWJGL, which implements all the rendering functionality that’s common to 2D and 3D rendering.
More generally, as it currently stands, the LWJGL renderer works pretty well on Windows, however, there are number of incompatibilities on Mac that make it difficult to use and in fact would require some initialization changes in PApplet itself.
@Andres — Thanks a lot for your answers. I noticed that the methods in processing.opengl.PGraphics2D are almost the same with those in processing.lwjgl.PGraphicsLWJGL2D. And they work normally except for some issues on the Mac. So I suppose we might need to implement some other new methods and I want to know how to get good ideas. Should I dive deeper in LWJGL? I hope I‘m asking the right question.
Also I’m drafting my proposal and I’ll post it here as soon as it’s finished.
@tianshuai the code in these two classes is almost the same because the only difference between the 2D renderers between the JOGL-based and the LWJGL-based libraries is that in the first case you inherit PGraphicsOpenGL and in the second PGraphicsLWJGL. And the latter is just a subclass of PGraphicsOpenGL that overrides the createSurface() method to return a PSurfaceLWJGL instead of a PSurfaceJOGL. Those are the ones that contain the binding-specific code.
However, this is not the biggest challenge of this project, the most serious issue is the incompatibility between LWJGL and AWT on Mac, I tried to provide some more details in this wiki:
I was looking at this recently, partly because running headless could also improve JOGL performance. It would be good to make that headless exception in runSketch optional and then see what works and what needs working around, because some of the AWT things you list should work OK headless.
Of course, an interesting fact in this context is that there’s just been a flurry of commits in JOGL over the last few weeks - it might be alive again!
@Andres Thanks again for your detailed answers and patience. I suppose that I’ve come to know the main task of this project, the incompatibility between LWJGL and AWT on Mac. After reading the wiki, I think Making AWT optional in PApplet might be a good solution since we can’t change GLFW. So I will focus on how to modularize AWT and handle the init stuff that’s in PApplet.main().
Tianshuai
