Move core away from OpenGL (JOGL) Dependencies

[!NOTE]
This issue is a Work In Progress about a long term goal.
It needs more discussion and is subject to changes.

Reasoning

There are a number of reasons to want to move away from OpenGL and JOGL:

• OpenGL is deprecated on macOS, and support could be removed at any time.
• JOGL is no longer actively maintained, raising concerns about stability, security, and the ability to adapt to new platforms.
• ...

Challenges

• Tight Coupling with Core Components: JOGL is deeply integrated with Swing, PGraphics, AWT, and Processing's event management system. This makes it difficult to migrate without breaking existing functionality.
• Rigidity of Modern Graphics APIs: Modern graphics APIs like Vulkan and WebGPU offer more control and performance but are more rigid in how the rendering pipeline is structured. Unlike OpenGL, which allows flexible, state-based changes at runtime, Vulkan and WebGPU require rendering pipelines to be defined upfront through fixed pipeline objects. This rigidity poses challenges for a creative coding tool like Processing, where sketches often rely on modifying drawing parameters on the fly.
• Backward Compatibility: Many sketches, libraries, and tools rely on JOGL-based renderers (P2D/P3D). Replacing them could introduce breaking changes. Small visual differences in rendering may also cause issues, especially in an educational context.
• ...

Research

• Look into OpenRNDR's approach: using Google’s Angle library. Emulates the entire OpenGL ES API. Bridges to Metal via MoltenVK, WebGPU via WGPU (Rust).
• LWJGL. There was an attempt by Andres Colubri and Jakub Valtar but it was abandonned. There is a working fork of processing where OpenGL was replaced with LWJGL by Neil C. Smith called libp5x.
• FX2D support for Processing exists via a library, but it has not been updated for years, and there are compatibility issues with recent versions of Processing. It may be a viable alternative to P2D.

Proposed Approach

• Modularize the Rendering Pipeline: Decoupling rendering from event management and UI layers would make it easier to support multiple backends in the future.
• Introduce a New Renderer Alongside JOGL: Instead of an immediate replacement, we propose developing and releasing a new renderer library (e.g., LWJGL-based) as an alternative to P2D/P3D. This would allow for gradual adoption, testing, and feedback without disrupting existing workflows.
• Phased Deprecation of JOGL: Long-term, we should consider sunsetting JOGL-based renderers once alternatives are stable and widely adopted. This would involve clear communication with the community, providing migration guides, and maintaining legacy support for a transition period.

Commencez par cartographier la manière dont JOGL est couplé à Swing, PGraphics, AWT et au système de gestion des événements de Processing. Lisez les références d’OpenRNDR, LWJGL, libp5x et FX2D, puis définissez un chemin de rendu modulaire permettant d’introduire un renderer alternatif aux côtés de P2D/P3D sans casser les sketches existants.