lwjgl3
lwjgl3 copied to clipboard
LWJGL
LWJGL 3 Android support
Description
Hello, It would be incredibly useful to have Android support for LWJGL 3, specifically for the vulkan/gles support. Having a single rendering engine to maintain is much simpler than attempting to maintain both a desktop version and an android version for GLES, and for Vulkan the lwjgl branch from 2017 is the only example I have found with android vulkan using java.
What would be required to get Android support in the main branch? Perhaps there are pieces of what is required that I can assist with.
Thanks, Trevor
Hey @tlf30,
What would be required to get Android support in the main branch?
Not much. However, it would not be a good experience because of how much LWJGL relies on MemoryUtil, MemoryStack and the struct classes for performance.
I don't have Android development experience, but one thing I learned from the 2017 tests was that Android... is not Java. LWJGL has been designed to work great with server-class JVMs, i.e. Hotspot and JVMs that compete with Hotspot. Unfortunately, almost every piece of knowledge and intuition I have about how Hotspot behaves does not seem to be applicable to Android. It felt like Android support would require a completely different LWJGL core module and overall design. Or actually, it felt like high-performance Java code is not even a thing on Android. You're supposed to write GUI stuff in Java and anything performance sensitive (e.g. a Vulkan renderer) in native code with the NDK.
I hope I'm wrong. In any case, I would not be comfortable (or even interested) to resume work on Android support, without the help of a person with deep knowledge of the Android ecosystem, how the available VM(s) work, what the best practices are for performance, how to get the most out of the available hardware, etc. Does such a person exist?
Hmm, unfortunately I'm afraid I do not have that deep of an understanding of what is going on under the hood in Android. I feel that you are correct though, it does appear that the intent is high performance code running in native and java for UI.
If someone is interested in helping with the low level components, I am more than happy to help with building the CI pipeline and packaging, along with any examples or demos.
iirc @orange451 did something with a mobile UI, but it wasn't android(?)
For my little mobile UI thing, I ended up writing a middle-layer that pipes LWJGL classes/functions in to GLFM library, so I can still use LWJGL for desktop, maybe you can do that for your android thing?
Yes, this is something that I worked on for a hobby project. I use another project called MiniJVM which is a custom JVM that works on windows, Mac, Linux, iOS, and android. It also has bindings to NanoVG and GLFM. I wrote some middle-layer code to pipe lwjgl functions to it so I can deploy my desktop application with lwjgl and my mobile app with MiniJVM. See my project JadeFX for more information.
However this means you give up any libraries not supported by MiniJVM, such as Assimp, which can be very important
Sent from my iPhone
On Jan 11, 2022, at 7:05 PM, SWinxy @.***> wrote:
iirc @orange451 did something with a mobile UI, but it wasn't android(?)
For my little mobile UI thing, I ended up writing a middle-layer that pipes LWJGL classes/functions in to GLFM library, so I can still use LWJGL for desktop, maybe you can do that for your android thing?
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.
Hi @Spasi, I have to agree that JVM and Android VM are not same thing, but both support Java language. I believe that Android VM performance shouldn't be a problem for custom renderer.
Is there any way to convince you that it is possible to add LWJGL support for Android?
Hello, I'm also interested in the support for Android on the main branch. Even a version which is not super performant would be great :). Mobile devices these days are so powerful that for most indie projects it doesn't matter. If there is such an option I would be happy to help in some way.
Even if the initial performance is poor, it doesn't have to stay poor forever:
- If there would be a working LWJGL android example, it would be easy for other people to do some modifications and experiment with the performance, and they might report a more efficient solution. (I have some interest in Android myself since many VR devices run Anroid, so I might even try this myself in the future.)
- The Android VM might evolve over time in our advantage.
I agree, if we could get some form of a 'preview' feature for android in the master branch where it is understood that it will not be included in any upcoming release, then it opens android development for people to being working on optimizing it.
I'm not sure if it would be possible, or perhaps there are already mechanisms in place (I have not check), to implement a feature as a preview feature that is not enable by default? I understand that implementing android required a couple changes to the core in the vulkan branch. I'm not sure if other platforms are impacted by those changes. If android could be packaged in such a way that it can be implemented without major impacts to other releases while it is in the 'preview' stage, then that would be great.
@Spasi let me know your thoughts. If you are willing, perhaps we can get a checklist of the steps needed to get the initial implementation in master.
I will never support vulkan the colors look off to me. I do agree you need android support but for opengl
I will never support vulkan the colors look off to me. I do agree you need android support but for opengl
@jredfox That's not really relevant to this issue but just to make it clear: Fundamentally, there is no visual difference between programs rendered using OpenGL and Vulkan. If you're observing color differences, the most likely cause is your configuration. If you want to debug your problem, you could start from one of the demo applications and tweak the code according to your needs. However, this issue is not the place to discuss this. Instead, if you need support it's better to use Discussions or the LWJGL forum.
I will never support vulkan the colors look off to me. I do agree you need android support but for opengl
@jredfox That's not really relevant to this issue but just to make it clear: Fundamentally, there is no visual difference between programs rendered using OpenGL and Vulkan. If you're observing color differences, the most likely cause is your configuration. If you want to debug your problem, you could start from one of the demo applications and tweak the code according to your needs. However, this issue is not the place to discuss this. Instead, if you need support it's better to use Discussions or the LWJGL forum.
it is relevent because A: did you read I was requesting adroid support for opengl B: vulkan is flawed in it's current state due to the fact I have seen countless games and pictures and compare them to any other graphics engine even of the same game and the colors look way different.
@jredfox You already have OpenGL ES support in Android, so what's your problem?
@Illithidek opengl ES isn't the same remotely the same it's stripped away alot of the features and that's why it's labeled as a different api. any game written using opengl will not run in opengl es
@jredfox are you trolling? The API is different because desktops and mobiles have a completely different range of functionality, you can't and won't ever be able to use OPENGL on Android because it just won't work.
Google it. “context compability missing” difference between the two “stripped away a lot of things and optimized for mobile devices” “missing features like drawing polygons” this tells me it’s not remotely the same and won’t work.
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows
From: Michał @.> Sent: Tuesday, February 8, 2022 10:19 AM To: @.> Cc: @.>; @.> Subject: Re: [LWJGL/lwjgl3] LWJGL 3 Android support (Issue #715)
@jredfoxhttps://github.com/jredfox are you trolling? The API is different because desktops and mobiles have a completely different range of functionality, you can't and won't ever be able to use OPENGL on Android because it just won't work.
— Reply to this email directly, view it on GitHubhttps://github.com/LWJGL/lwjgl3/issues/715#issuecomment-1032802374, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACKJBMJBZR2VG5VCALEMPMLU2E7ANANCNFSM5LVCC6WA. You are receiving this because you were mentioned.Message ID: @.***>
OpenGL basically has everything that OpenGL ES has, but more. OpenGL ES excludes the stuff that is difficult to implement for non-desktop devices.
And it sounds like you either have a bad Vulkan graphics driver or unorthodox color format support.
One concern for adding Android support is about who will maintain it. Publishing it with the expectation that someone will maybe fix it is optimistic. It's such a different platform to Windows, Mac, or Linux. If Spasi does publish one, I doubt he would want to maintain it.
As I see it, it's either publish a rotting Android version or publish nothing at all.
Android could be added as 'experimental' and not included in any release, just like the bullet bindings were. This will give us time to figure out if we can make the bindings better, or if we want to remove them.
I can see about getting the latest master building for android using the old android branch as an example.
@tlf30 that would certainly be helpful :). I'm actually a really curious what needs to be changed for simple interop. I think most of the stuff is pretty much ready. Currently lwjgl-vulkan is running well on Linux, so the migration to Android may not even be that much of a problem. If you decide to make some work on this topic, please share about the results.
That is called GLFM ( mobile version of GLFW3 ) but it is still in development and it doesn't have features like embedded images and fonts. I think better we use SDL2 because SDL2 has already supported for mobile.
jMonkeyEngine has a memory allocator implementation for android that works well (fast enough). I will look at what they are doing, perhaps some inspiration can be taken from there. From the vulkan side, I have been playing with it, definitely doable.
@Spasi, would it be possible to re-add the android surface and extensions in vulkan-gen? Not asking for full support, just the vulkan handles. Only asking for the patch file be updated to include the android parts. I know full well that these require underlying support from the core that is missing in order to use things like the android surface on Android. This will make it much simpler when attempting to query device information for Android support and implementing support for Android later on.
I think the important ones for now are the surface and the external memory android hardware buffer.
Just a thing that would be nice to have. Thanks, Trevor
PS: it also may not hurt to have other platform's handles as well, especially if they are just enum values. Thoughts?
Hey @tlf30,
The next snapshot will include the following extensions:
-
VK_ANDROID_external_memory_android_hardware_buffer -
VK_EXT_directfb_surface -
VK_KHR_android_surface -
VK_KHR_xcb_surface
Hey @tlf30,
What would be required to get Android support in the main branch?
Not much. However, it would not be a good experience because of how much LWJGL relies on
MemoryUtil,MemoryStackand the struct classes for performance.I don't have Android development experience, but one thing I learned from the 2017 tests was that Android... is not Java. LWJGL has been designed to work great with server-class JVMs, i.e. Hotspot and JVMs that compete with Hotspot. Unfortunately, almost every piece of knowledge and intuition I have about how Hotspot behaves does not seem to be applicable to Android. It felt like Android support would require a completely different LWJGL core module and overall design. Or actually, it felt like high-performance Java code is not even a thing on Android. You're supposed to write GUI stuff in Java and anything performance sensitive (e.g. a Vulkan renderer) in native code with the NDK.
I hope I'm wrong. In any case, I would not be comfortable (or even interested) to resume work on Android support, without the help of a person with deep knowledge of the Android ecosystem, how the available VM(s) work, what the best practices are for performance, how to get the most out of the available hardware, etc. Does such a person exist?
why you say android is not java. it can run java apps. most apps are java. java on linux kernel arm* specifically.
check jogamp for their support of android in jogl.
@goofyseeker311 It is simply that, as @Spasi mentioned, Android is in fact not Java. It uses most of the Java language, contains its own JDK that closely resembles the official JDK, but is missing key parts. The largest piece though is that Android does not run a JVM of any kind. It runs the ART (Android Run TIme): https://source.android.com/docs/core/runtime Android IS NOT Java on ARM, period. There is no JRE/JVM running.
Because of this, many of the low level constructs that LWJGL uses to interface native code to Java are slightly different, which makes most of the optimizations in LWJGL for memory management useless. LWJGL was created based on Java's JVM and how it interfaces to the native system using JNI, because Android works differently behind the scenes there are performance issues (mostly with memory management). TBH, these issues can be worked around, but still require a lot of fiddling. The other major issue is that the ART is itself slow, this is why high performance apps in Android use C++. The ART is not optimized like the JRE is and as such does not come with the major performance optimizations we are used to in the Java world that makes our normal programs run so fast.
well if you only feed the gpu, like its supposed to work, then being a bit slow does not matter on the cpu side.
how about tapping to the android ndk gpu access from lwjgl java. well that would lwjgl make porting easy. then lwjgl would be a compatibility porting layer of using NDK in the lwjgl way only.
namely NDK hello-vulkan at https://github.com/android/ndk-samples/tree/main/hello-vulkan/app/src/main
or maybe just wrap lwjgl opengles to default android GLES20 java class functionality. https://developer.android.com/reference/android/opengl/GLES20
I think that GLES2/3 class is exactly what you would need to wrap to from the GLES class of lwjgl. that would be a direct java wrapper nothing native, as the GLES class library is native on android.
yes a transparent wrap to the android java opengles library functions.
or use the NDK to make the interface to the opengl/vulkan native library with default VulkanActivity (window for android) then wrap it to lwjgl java library.