Hi @spasi. I’d like to continue the discussion from the previous LWJGL3 & Android thread which is locked now.
As more or less expected Google is declining to make a Vulkan Java binding for Android. Even giving what I think is a weak answer:
There are no plans to do a “pure” wrapping of Vulkan in Java. Vulkan would make a poor Java-language graphics API, and the overhead of JNI would mean losing many of the benefits that it’s supposed to provide.
I doth protested, but it’s not likely Google’s position will move. There are no more Java champions on the graphics side willing to take a stand within the Android team. This matches the sentiment I got from a light probing earlier this year. Hopefully they absolutely don’t create some new API on top of Vulkan as mentioned in a follow up to the above quote.
Anyway… I am 100% down to collaborate and help create and maintain a LWJGL3+ port for Android. Don’t worry about the API level needing to be high. It might even have to be API level 24/25; Android N and that’s fine. I do have some complex direct GL/ES code with the video engine and that’s even kind of neat because it would really be pushing things to get LWJGL3 setup to drive it (if possible). We can’t let this go unused! :
I’d be fine switching to LWJGL and doing an Android N release of the video engine if it could actually work; would have lot’s of data then on new device compatibility! Too bad I’ll have to stick to GL/ES, but it’d be interesting. I’d be glad to get some GL/ES and Vulkan demo code out there. I already have an Android GL/ES starter available which I’d rewrite for LWJGL3 via GL/ES in addition to a potential Vulkan version. In this effort I actually provide improved facilitating framework code where the Android API is long in the tooth.
I’ve got tons of devices with each generation of GPU and would be glad to test, refine, and work on any necessary optimizations.
It seems like Android N / API 25 w/ the switch to OpenJDK would be the first to get stable w/ GL/ES and Vulkan paths. I know there is a bit of sun.misc.Unsafe usage and / or some JNI fallback code for JVM optimization. Even if things started with Android N that’s great as there is a huge hole opening up on Android for performance graphics and LWJGL and can fill it.
So since I only have a cursory overview of LWJGL3 from poking through the source code I’d be curious to hear what you think will be the pain points? How are you handling JDK9 removal of sun.misc.Unsafe?
I think the first thing is to evaluate what’s potentially necessary / missing for an easier port. Maybe the Android team would be slightly helpful if there is something missing that could potentially be exposed in the future if no workarounds exist. Just kind of thinking out loud at this point… I’m down to make it happen though.