Wouldn’t using Wayland (which GLFW3 already supports to an extent) be a possible solution instead of X11 on the Pi? Its alot more lightweight than X11 and won’t require using any Pi specific API’s.
I may be overhyping this a bit, but I think this is a HUGE improvement. Does the Java agent negatively impact performance in any way? Is there a risk that it inserts unnecessary pushes/pops, or does it affect startup time/compilation stutter noticeably (if it’s used live, not preprocessed)?
In theory Wayland would be just great. Still some question over mouse/keyboard/touch of course.
Cas 
LibInput seems to be the most commonly used library by Wayland compositors to handle mouse/keyboard/touch. As the backend is still experimental not sure input support has been added yet but should eventually just be as simple as using GLFW’s api to handle input.
While still developing stuff you can ‘pipe’ everything through a custom class loader which applies the transformation.
But writing ClassLoaders :persecutioncomplex:
-ClaasJG
Thanks! Actually, I was quite interested in whether and how much people would perceive this as helpful or not. There is no performance penalty at runtime once the classes have been transformed. The code generation does exactly what javac or the Eclipse incremental compiler would do when wrapping the method’s source in a Java try-finally. There is however a startup penalty to pay for having to scan the methods that need transformation.
To reduce that as much as possible you can give the javaagent a custom package prefix so that it only looks in those classes. See the README.
Yes, true. I think the problem with using a javaagent is not so much that it complicates development (that can be as complicated as need be), but that it complicates productive deployment.
And when using a custom ClassLoader, yes you could do this also using a JVM argument “-Djava.system.class.loader=” (which of course just trades the -javaagent argument for this one ) or you would have to bootstrap your application differently, and therefore interfering with user/application code.
Looks like there already is support for mouse and keyboard in GLFW’s Wayland backend. Uses Wayland APIs and xkbcommon.
This change improves performance of Struct.mallocStack()/callocStack() that would implicitly access TLS, by storing the pushed MemoryStack once in a local variable at the beginning and then transforming the Struct.mallocStack()/callocStack() to Struct.malloc(stack)/calloc(stack) using that stack variable.
So even if you write suboptimal code not using a MemoryStack local, the agent now fixes that for you.
EDIT: With this change, static invocations on the TLS lookup MemoryStack.stackGet() will now transform to a simple load of the local variable which was already created at the beginning of the method.
For a comparison of what can be achieved with this, see this demo.
It is a port of the lwjgl3-demos Vulkan ClearScreenDemo demo to make use of autostack for all structs and NIO buffers. This completely eradicates all calls to struct.free() and Buffer.free()…
EDIT2: There is now also the possibility to offline transform classes inside a jar file with this transformation process. Just use the same autostack.jar as an executable jar.
While this thread is mostly LWJGL / Vulkan progress related I just want to post the issue filed in the Android issues tracker for an official SDK binding for Vulkan. And I didn’t even file it (stoked that someone else did!):
https://code.google.com/p/android/issues/detail?id=204085
Please star this issue if you are an Android dev. Of course LWJGL on Android will be great, but for stuff like my video engine updates for Vulkan / MediaCodec API will also need to be completed and an official SDK binding is the first step toward that support.
Seems like AMD is finally going a step further to the Linux driver release:
http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Beta-Driver-for-Vulkan-Release-Notes.aspx
A note concerning stack allocation in the LWJGL classes: After updating, my shader compiling and linking log handling code started crashing due to having a maximum length of 65536 chars, since the buffer was stack allocated and the stack was too small. This might be one of the few cases where NOT using the stack would be a good idea.
[quote=“theagentd,post:172,topic:56271”]
This has been fixed in the latest nightly build (#53), by allocating variable size buffers on the heap.
Also, a reminder: you can tune the default stack size with [icode]Configuration.STACK_SIZE.set(n); // n is in kilobytes[/icode].
Thanks for the fast fix! =D
Okay, has anyone found where the spec text is for the different extensions. For example, what’s the spec for VK_KHR_surface? According to https://community.amd.com/thread/197194 VK_PRESENT_MODE_FIFO_KHR is a guaranteed presentation mode, but I can’t find the text that actually says that.
What you need is the specification + WSI extensions, found here:https://www.khronos.org/registry/vulkan/
See changelog on PDF page 713 (document page 693/729)
That’s not the spec. That’s a list of functions and no information at all about them.
How do you know that this is not a spec? After all the title says “- A specification” 
and it somewhat specifies the operational and syntactic semantics of the functions.
I don’t think you’ll find anything more specy than that.
Also for your concrete question, look at PDF page 549.
But yeah I feel with you, we all would like to see more prose text in the form of a Programmer’s Guide, like with the fantastic Mantle Programming Guide and API Reference.
God, I love that document. Taught me most about Vulkan.
I’d like to see something like that for Vulkan, too, yes.
Hi
Is it possible to use LWJGL 3 Java binding for the Vulkan API without GLFW (with another windowing toolkit)?