Yes, but Java makes no difference here, really. In native code you would of course also rely on glGetError().
Java cannot help you there since the action mostly happens in the driver’s native code anyway.
I’m open to returning null, but not because glGetError is “expensive”. If the default behavior confuses users or makes debugging harder, then it obviously has to change.
Btw, I never said use glGetError, or fill your code with error checks. There is a reason LWJGL 3 does not have a “debug jar” like LWJGL 2, manual checking is obsolete now that we have the *_debug_output extensions and OpenGL 4.3+. Note that the error checking itself is not (more) expensive, the driver has to do it in any case, it’s reporting the error that causes performance problems. This issue goes away with debug output, because the debug callbacks may be called asynchronously (i.e. not in the same thread that called the OpenGL function and triggered an error) and you also have full control of the level of error/issue reporting.
What’s with drivers that do not expose that debug output extension?
Because of this asynchronicity is it then not possible for your program to crash because of a faulty GL call before being able to receive a GL error asynchornously by the driver in time?
[quote=“KaiHH,post:23,topic:53375”]
Are there such drivers? Note, this is for development only, the deployed application does not have to require a debug output extension.
[quote=“Spasi,post:22,topic:53375”]
If that indeed happens, you can enable GL_DEBUG_OUTPUT_SYNCHRONOUS.
Oh that’s neat! 
Just wanted to rule out all possible eventualities that can let me shoot myself in the foot.
Returning null gets my vote, as in the Java ecosystem, a ByteBuffer instance ought to be trusted (at least between glMapBuffer and glUnmapBuffer).
if you ask me, i vote for not returning any bytebuffer, just the long address would be make me happy.
basil_: that’s the difference between glMapBuffer and nglMapBuffer
oh, that’s new in 3.x ?
correct me but with 2.9.x ngl methods are not really available and even if, native methods already return a bytebuffer … right ? or am i blind again ?
basil_: this is the new ‘layered’ API design in LWJGL 3
sweet, thanks
The latest nightly build (#39) now returns null instead of a ByteBuffer pointing at 0L.
[quote=“basil,post:29,topic:53375”]
All the ‘n’ methods are publicly available in LWJGL 3. At the native side these are direct calls to the native function, there’s no magic happening, only casts from JNI types to native types. In theory, you could write your own high-level API on top of those and ignore anything LWJGL does at the Java side. Pointer values are mapped to long primitive values obviously. LWJGL creates ByteBuffer instances in Java, using Unsafe instead of JNI’s NewDirectByteBuffer.
very interesting ! i thought it was silly running an own “version” (less overhead, faster) of a bytebuffer based on unsafe. seems to pay out now.
cylab, we gotta code that swing/awt layer on 3.x!