[RFE] LWJGL 3.0

[Kai]

Oh, thanks for the hint with the "stable build is newer than latest nightly" !
The macosx native has also changed.
I will give it a try on Mac with the most bleeding edge "stable build". 

[apostolos]

Oh, thanks for the hint with the "stable build is newer than latest nightly" !
The macosx native has also changed.

Hi, this is Apostolos, I'm managing the new LWJGL servers and general infrastructure. We are deploying all downloads to a CDN ( Content Distribution Network ) so we can have faster downloads for each geo region. However, what you're describing shouldn't be happening. I'm downloading both files ( nightly & stable ) and they are - and should be - exactly the same. There may be an issue to the geo node you're using.

Could you please download both files again and send us the last modified date of the zip file as well the CRC32 of lwjgl.jar? ( For the CRC32 you could open it in WinRAR, it's the last column on the file list )

Thanks.

[Kai]

Hello Apostolos,

this is definitely an issue with some corporate firewalls or content proxies, it seems.
I have downloaded both .zip files over a corporate VPN (exiting at a region near Stuttgart) as well as without VPN (from Hamburg) and the download from Stuttgart got me different files, while the download from Hamburg got me both the same files...

So, this might be an issue with HTTP Cache headers?

EDIT: forgot about the timestamps and CRC32s:

The "old" download zip:
 timestamp: 09.11.2014 22:09
 CRC32: C50EEC66
The "new" download:
 timestamp: 11.11.2014 00:12 (for native/ it is 00:11)
 CRC32: C2547134

EDIT 2 (from 15:45:03 Germany, Berlin time):
  download over Stuttgart still gets me different files.
  old: 6.749.948 bytes vs new: 6.750.957 bytes

[spasi]

And yes the computer does support OpenGL 1.1+  .

Could you post the GL_VERSION, GL_VENDOR and GL_RENDERER strings? (use LWJGL2 or GLview)

[kappa]

And yes the computer does support OpenGL 1.1+  .

Could you post the GL_VERSION, GL_VENDOR and GL_RENDERER strings? (use LWJGL2 or GLview)

Using LWJGL 2 with the following code:

System.out.println("OpenGL version: " + GL11.glGetString(GL11.GL_VERSION));
System.out.println("OpenGL vendor: " + GL11.glGetString(GL11.GL_VENDOR));
System.out.println("OpenGL renderer: " + GL11.glGetString(GL11.GL_RENDERER ));

returns:

OpenGL version: 2.1.8545 Release
OpenGL vendor: ATI Technologies Inc.
OpenGL renderer: ATI RADEON XPRESS 200 Series

Yes, crappy card there but should still work

[kappa]

Could you please download both files again and send us the last modified date of the zip file as well the CRC32 of lwjgl.jar? ( For the CRC32 you could open it in WinRAR, it's the last column on the file list )

Downloaded both stable and nightly zips again, they are both identical now. The download a few hours before though was different.

[spasi]

kappa, I pushed a possible fix, please try again.

[kappa]

kappa, I pushed a possible fix, please try again.

Was getting old nightly zips, maybe firefox cache or something, but managed to get latest zips using a standalone download manager.

Anyway tested with the latest nightly builds and they work great now on windows 32bit, thanks for the fixes.

[kappa]

Tested the Gears demo on Linux 64bit (OpenSuse 13.1) with latest nightly build and can confirm that your fixes work and it all runs really nicely now. The windowed mode vsync works really well too (something lwjgl2 didn't do so well on linux).

Just curious, what part of lwjgl is the disruptor.jar used for? is it mac specific?

[spasi]

Yes, I've added a tiny note about Disruptor and OS X in README.txt, will make sure it's more visible when the new site is up.

The problem is, of course, the main thread situation in Mac OS X. GLFW, AWT, JavaFX, SWT, they're all competing for that first thread to spawn the event loop on. Java has different behavior with different JVM versions ( has changed at least on every major release, including Java 8 ) and then there's -XstartOnFirstThread. At least they have fixed AWT/JavaFX integration. Ideally, a modern Java app would never touch AWT (yes, including ImageIO), but currently LWJGL 3 assumes that you'd start with GLFW, without -XstartOnFirstThread, then go ahead and do something that initializes AWT (e.g. loading a texture image from disk). I had to implement two workarounds:

a) AWT is initialized automatically, before the native glfwInit is called. See org.lwjgl.system.macosx.EventLoop, can be overridden with -Dorg.lwjgl.macosx.nsloop.

b) Since the event loop is running on the AppKit thread and the LWJGL app is running on the main thread, we need to somehow transfer events between the two. This absolutely has to happen asynchronously (e.g. see glfwWaitEvents). The Disruptor is simply the highest performance solution to this problem. See org.lwjgl.system.glfw.WindowCallbackMacOSX for details. It's also very useful for game programming in general. It's designed for zero-allocation and is perfect for inter-process and inter-thread messaging, so I thought it'd be nice to bundle it with LWJGL.

All of the above is subject to change. This is the only difficult technical issue in LWJGL 3 and I currently don't have enough Mac OS experience to figure out a satisfactory solution. Best I can do is provide different solutions for different use cases (and JVMs!).

[spasi]

Latest news: with the latest nightly yesterday evening I had prepared a super simple example with setting the GLFW exception callback and without setting it.
The segfault happened again while the exception callback was set but it did not happen without setting it...

The Java callstack of the segfault:
[LWJGL] GLFW error    Code: 0x10008
     Description: Failed to retrieve display name
     Stacktrace:
org.lwjgl.system.glfw.ErrorCallback$Util.invoke(ErrorCallback.java:91)
         org.lwjgl.system.glfw.GLFW.nglfwInit(Native Method)
         org.lwjgl.system.glfw.GLFW.glfwInit(GLFW.java:414)
         simple.Main.main(Main.java:21)
Invalid memory access of location 0x20 rip=0x10bb90dd7
Segmentation fault: 11

This is what I tried today:

- I made a custom GLFW build that fires the same error ("Failed to retrieve display name"). This is a "soft" error btw, it does not make glfwInit to fail.
- I uninstalled the latest JDK 6 for OS X and installed an older version, same as the one in the trace (u65-b04-462).
- I'm running on Mavericks 10.9.5 as well.

The result is that I don't see the segfault, the callback is fired properly and I see the error, then the app works just fine. There must be something about that machine's environment. Why would it fail to retrieve the display name in the first place?

Another thing you may try: Call another GLFW function before glfwInit, e.g. glfwWindowHint(GLFW_VISIBLE, GL_FALSE). This will also result in your error callback being called, but I want to see if it will segfault outside glfwInit.

[Kai]

First of all: Thanks, spasi, for your quick responses and great support so far!

You are right. There must be an issue with that machine in general. For the time being, I think I'm gonna call it a day with that one. It has taken a lot more time and nerves than it should have.

I think I'm gonna wait for that LWJGL3 release and for glfw to "mature" a little bit more as well as for that particular Mac user to maybe upgrade to 10.10 and/or Java 7.

Right now as I am typing, I got a response from the Mac user about whether it makes a difference to set the error callback or not to set it (while also including the disruptor jar in the app):
The result was that not setting the error callback results in the application to work, but somehow without the glfw poll events function to recognize a ESC hit or a mouse click on the red "window close" 'button', which ought to close the application, but did not.

[spasi]

but somehow without the glfw poll events function to recognize a ESC hit or a mouse click on the red "window close" 'button', which ought to close the application, but did not.

The window close button simply sets a flag inside GLFW that you test in your main loop with glfwWindowShouldClose. For example, see in the Gears demo. Is your code doing that?

[Kai]

Well, it was just a guess that somehow the event notification may not work and that would also affect poll events. But, of course, you are right, the "should window close" function is what makes everything happen there.

And yes, I do it exactly like adviced in all tests. The very simple loop consist of:

while (0 == glfwWindowShouldClose(window)){
  glfwPollEvents(window);
  GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
  glfwSwapBuffers(window);
}

The thing is, on Windows 7 x64, that same demo app just runs fine, but on Mac OS X it persistently refuses to do so for days.

[spasi]

Yes, well, native callbacks are really awkward with JNI. GLFW's error callback and event callbacks are separate, but their implementation is similar.

It's really odd though that it only happens on that particular Mac and not on mine and kappa's. Would it be possible to send me your app (or a simple demo that also fails on that machine), see if I can reproduce the segfault locally? I really would like to get to the bottom of this.

If the user is willing to cooperate more, another thing you could try is a native GLFW demo, so that we can at least exclude a bug in GLFW.