afaik, it has to do with thread local storage being used, which means that depending on which thread calls the gl methods, different (and wrong) values will be in the threads associated context and TLS.
That is correct, but context switches are usually time consuming so its generally best not to do it that way anyways.
Sorry..I don't get it. As threads share same heap memory, why does it matter at all which thread try to invoke an opengl function? I even don't know why different threads have to set the context, as the one static opengl instance shouldn't even notice who calls theire commands. On the java side, threads can only be distinuished by explicitly get their current runtime Thread class..
Sorry for necroing, but this question was not answered, and the issue bugs me for long time too.
Why is necessary for LWJGL to control the thread access to OGL, why cannot this control be delegated to the application? If i am sure in my application that a block of code has exclusive access to GL, and other threads will not call GL commands at that time, why is GL access still restricted by LWJGL? As dronus said, and this is what i know too, Java threads share the same address space, and the GL function pointers should be the same for all of them. Is this not the case, or perhaps it is platform dependant?
The problem with queues is that Java likes to keep local copies of data for the threads, and transferring data from one thread to the rendering thread is problematic. Any chance of having the possibility to build LWJGL with static context?
Not related to threading and this topic but another build option could be to not add code to check for ByteBuffers if they are direct or not. Don't know how much would it affect performance (probably not much), but its again a thing that the application can do more efficiently.