Dear LWJGL users: please read and consider contributing to this topic. It is important and anything you have to say might prove useful.
If you don’t have an account on lwjgl.org, posting here is fine.
Hi
This new feature is interesting to me:
Why not supporting the same native libraries layout than JogAmp within a JAR? It would help to make a single cross-platform fat JAR or at least something supporting more than a single architecture:
http://jogamp.org/wiki/index.php/JogAmp_JAR_File_Handling#Usage
The idea consists in supporting such directories in which to look for the native libraries:
/natives/<os.and.arch>/
i.e:
/natives/android-aarch64/
/natives/android-armv6/
/natives/linux-amd64/
/natives/linux-armv6/
/natives/linux-armv6hf/
/natives/linux-i586/
/natives/macosx-universal/
/natives/solaris-amd64/
/natives/solaris-i586/
/natives/windows-amd64/
/natives/windows-i586/
Why isn’t possible to “free” a PointerBuffer directly? Do you provide a method to deallocate a direct NIO buffer constructed by Java itself and not by using malloc or jemalloc?
Please can you improve the Java documentation of the packages? It’s a bit hard to understand the roles of the subpackages for a newbie, isn’t it?
The initial design for LWJGL 3 was something like that. Unfortunately there were complains from several users that preferred a simpler structure, like in LWJGL 2. I personally preferred the subfolder structure, it was cleaner and didn’t require adding ugly suffixes to shared libraries.
Keep in mind though that LWJGL doesn’t care where the binaries come from. The artifacts are not signed (and never will be, it’s your responsibility), you’re free to change the existing structure, remove stuff you don’t need, etc. All library paths and names are configurable at runtime, so in theory you could replicate JogAmp’s design.
[quote=“gouessej,post:2,topic:55611”]
It is possible, for PointerBuffers allocated via the native allocator. Use memFree() from the MemoryUtil class. The same applies to NIO buffers and StructBuffer implementations.
[quote=“gouessej,post:2,topic:55611”]
No. Users that care about efficient deallocation should already be using native allocation instead of Buffer.allocateDirect.
[quote=“gouessej,post:2,topic:55611”]
This is planned for after the 3.0.0b release. Among other things.
Actually, it’s possible to support both, i.e looking at the root and looking at /natives/<os.and.arch>/, which is what JogAmp does. It helps to produce a fat JAR of the libraries for the newbies (they just have to add a single JAR into the classpath and it works) and it helps to provide something easy to test anywhere (imagine “java -jar lwjgl-unit-tests.jar”). Yes it’s possible to configure it at runtime, it’s better than nothing.
In my humble opinion, calling MemoryUtil.memFree() in PointerBuffer would make sense but it’s a matter of taste.
[quote=“gouessej,post:4,topic:55611”]
You can do this with LWJGL too. Put all binaries in a folder or inside a jar and it will work. The only difference is that with more OSes/architectures the LWJGL filenames will get uglier.
[quote=“gouessej,post:4,topic:55611”]
Yes, but it would break the symmetry with NIO buffers, which don’t have a free() method. I find symmetry more tasteful as a library designer.
As a user though, in my codebases that use LWJGL, I have added a free() method to all buffer classes via Kotlin extension functions.