[RFE] LWJGL 3.0

[princec]

How about a version that simply takes a Buffer rather than memAddress(buffer)? So at least you're not accidentally passing in some random long that compiles.

As for autotype... perhaps explicity generating methods with an 'a' suffix could provide autotyped versions of the "unsafe" methods:

FloatBuffer data = ...
glVertexAttribPointera(index, size, normalized, stride, data);
IntBuffer moreData = ...
glVertexAttribPointera(index, size, GL_UNSIGNED_INT, stride, data);

which would give us the choice of just going low-level without checks or higher-level and let LWJGL do a bit more type and parameter checking. At the cost of bloating the API a tiny bit.

Cas

[spasi]

How about a version that simply takes a Buffer rather than memAddress(buffer)? So at least you're not accidentally passing in some random long that compiles.

The problem with Buffer is that you cannot scale the current .position() by the element size (without instanceof checks). The memAddress method is overloaded to handle this.

As for autotype... perhaps explicity generating methods with an 'a' suffix could provide autotyped versions of the "unsafe" methods:

FloatBuffer data = ...
glVertexAttribPointera(index, size, normalized, stride, data);
IntBuffer moreData = ...
glVertexAttribPointera(index, size, GL_UNSIGNED_INT, stride, data);

which would give us the choice of just going low-level without checks or higher-level and let LWJGL do a bit more type and parameter checking. At the cost of bloating the API a tiny bit.

I'm not sure how this is different from what we have now. You don't want to mix low-level and high-level versions when auto-completing?

[princec]

My thinking was along the lines of:

If you have to wrap every call that takes a Buffer with a memAddress(buffer) then you may as well make Buffer the signature and unwrap its address inside LWJGL instead.

As for autocomplete - well, yes, I would like to see them both if they were available, and then I'd choose And if I got really sick of some of them I'd just get autocomplete to filter out the ones I don't like. The explicit addition of a new method suffix eg. 'a' would at least help to differentiate the calls.

CAs

[spasi]

Used IntelliJ auto-complete to do a few mockups, see the attachments. 1st is the current LWJGL state, 2nd is without AutoType, 3rd is princec's suggestion, 4th is princec's without AutoType.

In terms of aesthetics, I like the 2nd and 4th. But I absolutely hate the 'a' postfix and I can't think of anything nice to use there. Personally, it doesn't bother me that the high-level overloads are mixed with the lower-level ones in #2.

In terms of usability, the use-case with the mixed data in the same buffer that you suggested, can be handled in two ways:

- Use a ByteBuffer for everything.
- Use a ByteBuffer for the raw data and the OpenGL call, but use a FloatBuffer view on top of it to fill fp data at the appropriate offsets.

[spasi]

In any case, I don't think the Buffer version is a good tradeoff. If we're willing to pay the price of runtime type discovery*, we might as well remove the other overloads (see the attachment).

* Depending on how we write this, the JVM may able to statically identify the type used at a given call site. But I'm afraid the increased bytecode size will affect inlining at a higher level. Will have to do some testing.

[spasi]

The latest build (3.0.0b #14) features the new OpenGL extensions announced today at Siggraph. Nvidia has released a driver that supports all the new extensions.

#14 also features OpenGL ES 3.2 support.

[princec]

Thinking that on reflection, no pun intended, that #2 might just be the most intuitive, and let the user sort out passing the correct gl_type in whether they're passing in FloatBuffers or IntBuffers or whatever. Which could allow some amusing "casting".

Cas

[spasi]

Build 3.0.0b #16 deduplicates JNI methods that are binary compatible. This was possible because LWJGL 3 did nothing in JNI calls, other than casts and the actually native function call. The JNI methods in bindings are now gone and there's a new org.lwjgl.system.JNI class that includes the distinct set of JNI methods, shared across all bindings. The JNI class is auto-generated, based on the active bindings at build time.

This change had a significant impact on the native binary sizes:

liblwjgl.dylib: 474KB, down from 659KB

liblwjgl.so: 249KB, down from 465KB
liblwjgl32.so: 239KB, down from 439KB

liblwjgl.dll: 271KB, down from 416KB
liblwjgl32.dll: 241KB, down from 395KB

(the Linux and Windows binaries are upx compressed)

[Kai]

Wow, that is really awesome! Like!
Makes high anticipation for a modular custom build that really only contains the necessary things and keeps the generated artifacts lean and mean.

EDIT: Hmm... for me, the 64-bit lwjgl.dll shrunk a bit more to just 247,808 bytes with default "ant" build, recent glfw head and upx -9.

[spasi]

Thinking that on reflection, no pun intended, that #2 might just be the most intuitive, and let the user sort out passing the correct gl_type in whether they're passing in FloatBuffers or IntBuffers or whatever. Which could allow some amusing "casting".

API breaking change: Build 3.0.0b #17 implements #2, all FLOAT "autotyped" methods have been replaced with methods that require an explicit type argument.

EDIT: Hmm... for me, the 64-bit lwjgl.dll shrunk a bit more to just 247,808 bytes with default "ant" build, recent glfw head and upx -9.

Most likely because you're building with VS2013. The CRT (which is statically built into LWJGL) has changed significantly in VS2015.

[kappa]

..
This change had a significant impact on the native binary sizes:

liblwjgl.dylib: 474KB, down from 659KB

liblwjgl.so: 249KB, down from 465KB
liblwjgl32.so: 239KB, down from 439KB

liblwjgl.dll: 271KB, down from 416KB
liblwjgl32.dll: 241KB, down from 395KB
...

oh nice, this is a super awesome change, much more features than LWJGL2, faster and now smaller too.

[Hooji]

It seems that all the previous mentions of adding Mantle support have been removed...

Does this mean that the Mantle support will not be moving forward?

I still think it would be very nice to have (optional) Mantle support in LWJGL.  Please consider reviving the plan!

I am *very* excited about the upcoming Mantle support!

I'd love to get started with it asap. Any idea when an early release might be available?

Are the Projects Valhalla or Panama going to be of any help to LWJGL's structs implementation? If so, might be worth waiting for them as an official solution.

Valhalla, no. Anything they do will be heap-based for sure. Super-interesting and useful if you're doing server programming, but does nothing for native interop. Panama is more promising, but we're talking Java 10 (at best). LWJGL 4 will be out when that's mainstream enough.

Just curious, is the Mantle library even relevant anymore or worth implementing? given that its specific to AMD hardware and most are now throwing their weight behind Vulkan (including AMD) and will likely do what Mantle does but better.

Yes, for a few reasons:

- It won't affect the official LWJGL build. The Mantle bindings will be an optional module and you'll have to manually build LWJGL to use it. It's currently Windows-only anyway.

- Mantle is not dead. AMD will use it as a faster way to get exciting new features to customers. Like NV's CUDA. If you only care about Mantle 1.0 features, then obviously Vulkan will be better (and that's AMD's suggestion too).

- I think many people are excited about Vulkan and Mantle is a very nice way to get a glimpse of what's coming. The two APIs are very similar and you can start preparing for Vulkan right now.

[spasi]

I had much less time this summer to work on LWJGL than I was expecting. I had to revise my plans and focus on fixing issues, finalizing the public APIs and releasing the beta. After that's done, I'll work on bindings again. Though we're getting very close to the Vulkan release now and I'm not sure it's useful having Mantle bindings anymore.

[spasi]

LWJGL has always supported a few system properties (e.g. -Dorg.lwjgl.util.Debug=true) that could be used to configure its behavior. In LWJGL 3 there are several more and it was starting to get out of hand. Passing several JVM launch arguments isn't the most convenient way to configure a library.

There is now support for programmatic runtime configuration with the org.lwjgl.system.Configuration class. This works in addition to the system properties, they can still be used. The new class is an enum of all the available options and they should be adequately documented. Let me know if something needs clarification. Example usage:

public static void main(String[] args) {
	Configuration.LIBRARY_PATH.set("libs"); // equivalent to -Dorg.lwjgl.librarypath=libs
	Configuration.DEBUG.set(true); // equivalent to -Dorg.lwjgl.util.Debug=true
	// start using LWJGL
}

It's available in nightly build 3.0.0b #37.

[spasi]

Almost 3.5 years after the original post in this thread, the current LWJGL 3.0 nightly build is the first release candidate.

Now is the time to try it out and raise any issues you might have with the API. See this post for changes since 3.0.0b.