[RFE] LWJGL 3.0

[Kai]

Do you think that LWJGL adds new libraries with such high frequency that updating an automatic renaming script (via Ant or something) would be such a big burden?
Currently LWJGL also has a renaming script, which comes in the form of copying the downloaded files to the respective OS'es arch's folders. So changing that into a simple renaming would not be a big issue, in my honest opinion.

[spasi]

Scripting the actual renaming isn't a problem, but the naming scheme is, for some libraries. For example, the official name of the OpenAL library is OpenAL32.dll on Windows:

LWJGL 3:
    windows/x86/OpenAL32.dll
    windows/x64/OpenAL32.dll

LWJGL 2:
    OpenAL32.dll
    OpenAL64.dll (what?)

LWJGL 3 (proposed):
    OpenAL32_x86.dll
    OpenAL32_x64.dll

Make it ugly and non-standard just because some tool has trouble with extracting files?

[Kai]

But isn't the actual name of a DLL completely irrelevant here?
Personally I find it the most irritating that OpenAL for 64 bit is actually called OpenAL*32*.dll.
I would vote for just changing that and the corresponding ALC.java:35.

[kappa]

What are the tools that have trouble with the current scheme?

Most of the far jar tools namely: Eclipse's built in executable jar tool, One-Jar, Launch4j, JarMatey, etc.

We currently have to only deal with OpenAL and LWJGL itself. What happens if we later add more and more libraries? It becomes a pita to have to rename every 3rd party library to exactly match the LWJGL naming scheme.

Yeh good point, naming conventions do differ between native libraries with some including the arch name and others not. Guess it just boils down to picking a convention we want to stick to for LWJGL, but do agree with Kai, native names don't really matter much if they are in our control (unless there are plans to use natives found on a system or something). We should try to go with a convention that allows the most flexibility for users and not stick with one that restricts certain types of use (such as wanting them all in one folder). An option that might keep everyone happy, maybe there could be an option for users to manually set library names (e.g. using System.setProperty) rather than having fixed names.

[shivshank]

Why not another system property that selects the naming/layout scheme?

Can there then be an additional build script/target that switches the active library layout scheme? Say it walks the directories, renames, and moves all of the native libraries?

maybe there could be an option for users to manually set library names (e.g. using System.setProperty) rather than having fixed names

The code is already there for that, is it not:

create(System.getProperty("org.lwjgl.openal.libname", libName));

(from ALC.java)

[kappa]

The code is already there for that, is it not:

create(System.getProperty("org.lwjgl.openal.libname", libName));

(from ALC.java)

Nice, didn't notice that one, just need one for the lwjgl native ("org.lwjgl.libname") before its usable for things like all natives in one directory.

So the following line in org.lwjgl.Sys

private static final String JNI_LIBRARY_NAME = "lwjgl";

could be changed to

private static final String JNI_LIBRARY_NAME = System.getProperty("org.lwjgl.libname", "lwjgl");

[spasi]

just need one for the lwjgl native ("org.lwjgl.libname")

Added support for this.

[advanced_set]

- Without -Djava.awt.headless and with a very small fix inside GLFW, AWT before GLFW works perfectly. I could even have a GLFW window side-by-side a JFrame. Only limitation: any AWT windows must be disposed before GLFW, otherwise the AWT windows hang without an event loop.

Any updates on this? (It seems that GLFW 3.1 is nearly there)

I was playing with GLFW / Swing on OSX (only for a OSX menubar). Newer nightly builds now ask me to use -XstartOnFirstThread. If I use it and start GLWF first, AWT/Swing seem not to work. If I start AWT/Swing first they erase the -XstartOnFirstThread flag as you said and GLFW does not load.

Will this small fix become available?

UPDATE:

I tested with the option with -Djava.awt.headless=true, and the result was this:
Exception in thread "AWT-EventQueue-0"
"Application.setDefaultMenuBar() only works with the Aqua Look and Feel"

Then I saw what headless do I realised that it definitively is not a solution for any application other than a single-windowed game (even multi-windowed games, map editors, etc may need auxiliary gui components, floating windows, etc)

--
What JGLFW do different?

"Integration with Swing or AWT is not possible (so, no Applets either). You can however open Swing and AWT frames besides GLFW windows."

https://github.com/badlogic/jglfw

--
UPDATE 2:

I see the issue is old:
http://www.java-gaming.org/topics/lwjgl3-moves-to-glfw/30793/view.html

I spent a lot of time researching this but the issue is definitively beyond my expertise. I thought I only need to create windows and render stuff in the main thread (i.e. whatever thread started launched my application). If I have my app running before any calls to AWT I do not see how it can interfere with GLFW unless, if I understood correctly, the JVM reserves a thread for AWT and launches your app in a secondary thread (if you do not use -XstartOnFirstThread).

Before the changes you guys did in EventLoop.java it seemed to work. (Actually, I did not understood why lwjgl would needed to initialise AWT in the old version)

[kappa]

Quick question, I am querying GL_MAX_TEXTURE_SIZE using GL11.glGetInteger which according to the OpenGL docs returns 1 value.

IIRC in LWJGL2 you were required to provide glGetInteger a 16 int buffer e.g.

IntBuffer buffer = BufferUtils.createIntBuffer(16);
glGetInteger(GL_MAX_TEXTURE_SIZE, buffer);
return buffer.get(0);

Noticed that in LWJGL3, you can use BufferUtils.createIntBuffer(1); without any exception being thrown, is this a change now allowed or is it still recommended to use a 16 int buffer?

[spasi]

Any updates on this? (It seems that GLFW 3.1 is nearly there)

I was playing with GLFW / Swing on OSX (only for a OSX menubar). Newer nightly builds now ask me to use -XstartOnFirstThread. If I use it and start GLWF first, AWT/Swing seem not to work. If I start AWT/Swing first they erase the -XstartOnFirstThread flag as you said and GLFW does not load.

Will this small fix become available?

I'm afraid not. I would love to be proven wrong, but I've spent a lot of time trying to make GLFW+AWT work together and could not find a clean solution.

Keep in mind that we're currently in the process of finalizing LWJGL 3.0. Any feature added officially will be a burden throughout the library's lifetime. Right now AWT integration feels hacky, broken, inelegant. Even if that's true for only one of the 3 OSes we support, if we officially enable AWT integration the support pain will be extremely painful. Just like it was with LWJGL 2. LWJGL 3 has been designed to allow for such additional features to be layered on top of the base library, there's basically nothing that LWJGL does internally that you can't do externally. If someone figures out a decent solution, it doesn't really have to be part of the official distribution.

I spent a lot of time researching this but the issue is definitively beyond my expertise. I thought I only need to create windows and render stuff in the main thread (i.e. whatever thread started launched my application). If I have my app running before any calls to AWT I do not see how it can interfere with GLFW unless, if I understood correctly, the JVM reserves a thread for AWT and launches your app in a secondary thread (if you do not use -XstartOnFirstThread).

Before the changes you guys did in EventLoop.java it seemed to work. (Actually, I did not understood why lwjgl would needed to initialise AWT in the old version)

The problem is the inherent design of OS X. You cannot have two threads driving a GUI event loop, it must be only one and it also has to be the first thread of the process. So, you need 1 event loop driving two different libraries. AWT and SWT have explicit support (i.e. nasty hacks) for such a cooperation, but GLFW is entirely oblivious to that. A working solution would require modifications to GLFW, rules for which library is initialized first, destroyed last, etc. I firmly believe this is outside the scope of LWJGL 3 and we don't have the people or time to support such a solution.

If I were building a GLFW + Swing/JavaFX app right now, I would use a different process for the GLFW window(s). The first thread limitation only applies per-process and you could use an ultra-fast IPC mechanism (e.g. Disruptor) to communicate between the two processes.

[spasi]

Noticed that in LWJGL3, you can use BufferUtils.createIntBuffer(1); without any exception being thrown, is this a change now allowed or is it still recommended to use a 16 int buffer?

Yes, the check has been changed from 16 values to 1. The logic behind that decision is that there's nothing LWJGL can do to completely eliminate possible crashes, especially with OpenGL. Instead of pretending that we're a somehow "safe" library, we prefer convenience and never impose artificial limitations that don't exist in the native API.

[advanced_set]

Thanks for the reply. This reduces a bit the scope of the library but I agree you're going the right direction. Cleaner and smaller is better.

If I were building a GLFW + Swing/JavaFX app right now, I would use a different process for the GLFW window(s). The first thread limitation only applies per-process and you could use an ultra-fast IPC mechanism (e.g. Disruptor) to communicate between the two processes.

Hum... I 'll have a look, this could work.

[kappa]

Yes, the check has been changed from 16 values to 1. The logic behind that decision is that there's nothing LWJGL can do to completely eliminate possible crashes, especially with OpenGL. Instead of pretending that we're a somehow "safe" library, we prefer convenience and never impose artificial limitations that don't exist in the native API.

Nice, this approach is much better. In any event, the layer of code above LWJGL should be checking and catching these things anyway.

Also its more memory efficient now, yay (not that a couple of extra int's make that much difference on today's systems)

[Xpe]

Hi,  what is the best approach to have the same decorated functionality (re-sizing, moving, maximize, etc.) when its off ?  Im currently using libgdx scene2d for UI stuff and wonder is there is a easy solution to mimic it. 

[Kai]

I'll work on freetype after those two are done.

Just want to ask, is there any progress on this? It would be really helpful for me to have freetype available.