New iOS SDL3 + GLES 3.0 Angle Metal backend#2775
Conversation
|
🖼️ Screenshot tests have failed. The purpose of these tests is to ensure that changes introduced in this PR don't break visual features. They are visual unit tests. 📄 Where to find the report:
✅ If you did mean to change things: ✨ If you are creating entirely new tests: Note; it is very important that the committed reference images are created on the build pipeline, locally created images are not reliable. Similarly tests will fail locally but you can look at the report to check they are "visually similar". See https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-screenshot-tests/README.md for more information Contact @richardTingle (aka richtea) for guidance if required |
There was a problem hiding this comment.
Code Review
This pull request migrates the iOS backend to the libJGLIOS framework, replacing legacy native code with generated bindings for GLES and OpenAL and significantly improving input handling for touch, mouse, and gamepads. The changes also include a simplified spherical harmonics baking process and the addition of an iOS test chooser. Reviewers identified several critical issues, including a shader compilation error in IBLSphH.frag caused by the missing Hammersley function and a type mismatch. Additionally, the PR introduces a GPU resource leak in IBLGLEnvBakerLight, performance bottlenecks in JmeIosGLES due to excessive heap allocations, and a potential rendering bug in the IGLESContext sRGB blit logic. Clarification is also requested regarding the intentional disabling of hardware shadow comparison on iOS.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request migrates the jMonkeyEngine iOS backend to use the libjglios library, replacing custom native C/Objective-C bindings. Key changes include the addition of an iOS example launcher, updated input and joystick handling, and the implementation of a linear framebuffer blitting mechanism for gamma correction. The reviewer correctly identified an opportunity to optimize the glGen* methods in JmeIosGLES to reduce memory allocations by utilizing direct buffer manipulation.
| public static void glGenBuffers(int n, int[] buffers, int offset) { int[] tmp = new int[n]; GLES.glGenBuffers(n, tmp); System.arraycopy(tmp, 0, buffers, offset, n); } | ||
| public static void glGenFramebuffers(int n, int[] framebuffers, int offset) { int[] tmp = new int[n]; GLES.glGenFramebuffers(n, tmp); System.arraycopy(tmp, 0, framebuffers, offset, n); } | ||
| public static void glGenRenderbuffers(int n, int[] renderbuffers, int offset) { int[] tmp = new int[n]; GLES.glGenRenderbuffers(n, tmp); System.arraycopy(tmp, 0, renderbuffers, offset, n); } | ||
| public static void glGenTextures(int n, int[] textures, int offset) { int[] tmp = new int[n]; GLES.glGenTextures(n, tmp); System.arraycopy(tmp, 0, textures, offset, n); } |
There was a problem hiding this comment.
The current implementations of glGen* methods (like glGenBuffers, glGenFramebuffers, etc.) create a temporary array, call the native function, and then copy the results back. This pattern introduces overhead from extra allocations and data copying.
If the underlying libjglios native bindings can be updated to work directly with java.nio.Buffer or array slices, it would be more efficient. For example, glGenBuffers could be implemented as:
public static void glGenBuffers(int n, IntBuffer buffers) {
GLES.glGenBuffers(n, buffers);
}If the native bridge has limitations that make this difficult, the current approach is a valid workaround, but improving the native bindings for direct buffer manipulation would be a valuable performance optimization.
New iOS backend built around a set of native bindings for sdl3, angle and openal.
Contrary to the current iOS backend, this one does not rely on deprecated platform native gles or unofficial JREs, instead it builds as a native application with graalvm 21 and binds to google angle on Metal.
This should make iOS development and capabilities on par with the new desktop Angle backend and android backend, with support for modern java.
Currently WIP.
To test run on macos (make sure to have xcode installed)
if a real device is connected to xcode, the example chooser will be installed there, otherwise it will start a simulator.
needs rebase on #2779
Known issues so far: