[RFE] remove Mac OS X -XstartOnFirstThread requirement

[badlogic]

Hi,

having to supply this VM argument is a bit terrible. For JGLFW, we actually modified GLFW itself so we don't have to do this. Our fork is a bit out of date, but it should be simple to port those changes over. See https://github.com/badlogic/jglfw/tree/master/jglfw/jni/glfw-3.0

Related in terms of user friendliness: I'm a big believer in loading shared libraries from Jars. Any chance you'd accept a pull request for that?

Thanks,
Mario

[spasi]

having to supply this VM argument is a bit terrible. For JGLFW, we actually modified GLFW itself so we don't have to do this. Our fork is a bit out of date, but it should be simple to port those changes over. See https://github.com/badlogic/jglfw/tree/master/jglfw/jni/glfw-3.0

I would like to avoid having to patch GLFW. Why is it such a problem? Is it the argument itself (SWT has the same requirement)? Or are you interested in playing nice with AWT?

Related in terms of user friendliness: I'm a big believer in loading shared libraries from Jars. Any chance you'd accept a pull request for that?

Sure, assuming there's a fallback to the current loading.

[Kai]

Loading natives from jars would be awesome!

Since this would enable the use of Java WebStart with LWJGL 3, specifying the jars containing the natives with OS/arch conditionals in the JNLP.

There are some questions that come to my mind when packing natives in jars, such as:

- where do you extract the natives to? Something like ${java.io.tmpdir} or ~/.lwjgl or via -Ddir/property?
- where do you expect the natives to reside in the classpath? All in one root classpath entry, like SWT does? Or OS/arch specific subpackages?
- do you employ a caching strategy so as to not having to unpack the natives every time? if so, how do you determine whether the cache needs flushing? timestamp of the shared library entry in the zip/jar file? Computed or provided checksum file?
- apart from loading, do you also provide a solution for deploying? Such as packaging the natives into OS/arch-specific JAR files during LWJGL build?

Cheers,
Kai

[abcdef]

I currently put all my natives in to jars and extract them on startup. You don't need webstart to do this though. The basic strategy is to :

• Work out which OS you are on
• Extract the required files to the local temp directorty (java.io.tmpdir)
• Add those files to the required system property (org.lwjgl.librarypath for LWJGL natives)

I have a script I run off of the build directory to add the natives to specific diretories and then jar up in to a natives.jar

I beleive the applet loader in LWJGL 2 already did something similar to this.

[Kai]

I know that I don't *need* Java WebStart for that to work ...
It's just that when using Java WebStart and deploying your natives in OS/arch-separated JARs, you can significantly reduce the download size, because WebStart will figure out which OS/arch libs it needs to download.

[SHC]

I think that's not of big use (talking about separation of native JARs), as the JAR is just 1.58 MB (with the latest nightly), and that is pretty small.

[Kai]

Actually, the current LWJGL download is 3,632,299 bytes (classes and natives zipped).
The windows 64-bit only version of all modules would be 1,854,339 bytes, which is half of it.
But yes, I too think that it does not make a very big difference.
But I try not to evaluate or judge any facts, just propose them as facts.
So, if someone would like to do that or not, it still would reduce the overall download size, had one chosen Java WebStart as deployment strategy. I don't say that one *should* use WebStart or that it is encouraged or discouraged.
Again, I am not trying to evaluate or judging the possibility. I just say that it does exist and if someone wants to use it, then he/she will have good reasons to do so.
And then he/she might want to separate the download of the natives per OS/arch, which will reduce the overall size by half.

[badlogic]

I would like to avoid having to patch GLFW. Why is it such a problem? Is it the argument itself (SWT has the same requirement)? Or are you interested in playing nice with AWT?

It's the argument itself. For many newbies it is none-obvious that they have to specify this when developing or deploying the app. Nobody RTFMs. I do not care for AWT.

I agree that patching GLFW is terrible though. For now i'll just send a PR for natives loading that's backward compatible with the current way of loading things.