Jump forward meaning 11.0.8? Or that we need to continue updating past that once the JEP is available? Or something else I'm missing?

Apple Silicon would also be another vote for LWJGL, since the move will almost assuredly require a Metal backend, which LWJGL may either have working (is it via bgfx?) or is at least considering.

I'd be willing to bet we won't see JOGL running on ARM Macs for a bit, if at all. It's a ton of work that I doubt the maintainer will be able to have time for.

Swapping out JOGL for LWJGL as the default for P2D/P3D would be a change that could break a lot of older code, so I'd prefer to make it an optional library for 4.x, but if we're looking for something that will work for a couple years, we might be better off making the switch.

Jump forward meaning 11.0.8? Or that we need to continue updating past that once the JEP is available? Or something else I'm missing?

Just that we need to keep updating past. We should be able to stay on the 11 train (I guess there's a very very small chance that it doesn't go into 11?).

Apple Silicon would also be another vote for LWJGL

Agreed

but if we're looking for something that will work for a couple years, we might be better off making the switch.

Yeah I agree with this as well. I would have preferred we kept JOGL but it's looking like it might be difficult with this plus #124

We already have a working version of the LWJGL renderer that is running on all 3 OS, but it requires a couple of new methods in PApplet (no way around that, particularly on macOS!). We're also planning on still supporting JOGL at some point, but need to do this also by abstraction of the JOGL code into a separate package (for us JPMS module). This would allow shipping either renderer rather than both for platforms / exported sketches.

I'm still happy to help with backporting and fixing this upstream if at all possible.

I'm not sure if LWJGL does have a Metal backend?! They do have Vulkan, which has a Metal compatibility layer as far as I know. But I have a feeling OpenGL(ES) on Metal is a more usable future option?

The next Java LTS (17) is out in a year. I'd be surprised if the support didn't get backported to 11 by various vendors though.

@neilcsmith-net (sorry to go slightly offtopic, but where can I test LWJGL renderer?)

@clankill3r outside of PraxisLIVE, where it's the version we ship with but currently without ARM binaries, the source is at https://github.com/praxis-live/libp5x and the maven binaries are at https://search.maven.org/search?q=g:org.praxislive.libp5x Email me directly if you want any more info (email on GitHub profile).

A quick test has things running a little better than expected in translation mode (whatever they call it) on the M1, so I'm feeling a little better about sticking with JOGL as the default to keep things compatible in 4.x. Fingers crossed…

Also locking this thread to so we can keep it focused on implementation instead of general discussion about M1 (as always, the forum is a better place for that). Normally I'd close this since it's too broad (and therefore invites things that get off-topic quickly) but we do need a place to discuss a baseline implementation/testing/plans for M1.