X Error of failed request: RenderBadPicture (invalid Picture parameter) #149
Comments
|
I have tracked down the problem and can now offer a minimal reproducing example. The problem is caused by a small "loading" splash screen that is shown during the OpenGL initialization. It looks like there are some kind of side effects between LWJGL/GLFW and Java Swing. In can reproduce the problem like this (I hope it is okay to post in Scala, let me know I should provide a Java version): It looks like the splash screen must satisfy a few conditions in order to trigger the
Now the question is: Why and how does LWJGL 3 or GLFW interfere with this Swing stuff? I'm not sure if this really is a LWJGL bug, but at least this code seem to work in general and also with LWJGL 2. |
|
GLFW does not interact with AWT/Swing on Linux. A possible explanation for the crash could be that Swing produces an X error, which is picked up by GLFW and the program aborts. I think this is possible due to how error handling in Xlib works. I'm afraid I won't have time to look into this any further. Keep in mind that LWJGL 3 does not (officially) support AWT/Swing integration. I'm wondering though, why do you use a custom JFrame for the splash screen and not the JVM's built-in support? What happens if you replace the JFrame with:
and call |
|
Ah I see, now that's a bit tricky. Thanks for the feedback! I ran some tests with the regular The reason why I wasn't using a regular splash screen is that the functionality is limited. For instance, I wanted to add a message log to show the steps of the initialization. Maybe official support for Swing might be a nice feature for the future. My software for instance is a VR-only application. In such a case it might not be unusual to have some kind of traditional UI on the regular screen (showing some status or even for configuration), with the graphics engine running in "direct mode" on the HMD. |
If the initialization process is that long, you could use an undecorated GLFW window as a splash screen. A simple texture and (Animated GIFs will be tricky though. Will require some internal functions in
Please see #101. There are ways to make AWT/Swing/JavaFX integration work, but the choices are:
It's a lot of pain for solutions that don't really satisfy anyone. LWJGL 3 is designed to be extremely lightweight and not make any choices for the user. For example we have JAWT bindings, you can use that to implement LWJGL 2's solution, but it won't be provided out of the box.
The solution I would use and the one I generally recommend when you have separate "scene" and "GUI" windows: use two processes (i.e. two JVM instances), one for each window, and an IPC solution for dispatching messages between them. This way you isolate each windowing system and you can basically do whatever you want, even on OS X (which is the most problematic OS for such things). |
|
Another possible solution for showing a splash screen could be using the SWT library instead of AWT/Swing/JavaFX. Its works well with LWJGL3 and supports loadings and displaying animated gifs (or even a native progress bar). |
|
I have the same problem using the nightly build, my application uses LWJGL to draw a map, and uses Swing GUI to, for instance, allow the user to select the map he wants to display. I have a Swing Dialog before the creation of the glfw window that works fine, but after creating the glfw window, I use events to open other GUIs, such as glfw Key Press callback, despite using the Swing EDT, my application crashes with the same error message a few seconds after the GUI has closed, which is very strange.
I guess I'm going to have to change my approach to GUIs using LWJGL. |
|
@pierr3 could you post a small sample that errors out or can you only get it to happen when you have a large amount of code. |
|
@ShadowLordAlpha I don't have a small sample, but it happens with basically this kind of code: https://gist.github.com/pierr3/630fc76dd8c987500d8ed7895e46ec59 |
|
I have the similar problem.Mine has nothing to do with Swing but in jMonkeyengine. I am on I asked my problem in jme forum but i got no response so decided to ask it here. |
|
Could you try with LWJGL 3.1.0? Can you force your system to use the AMD GPU instead of the Intel HD? |
I tried to build with 3.1.0 by editing build.gradle in jme3-lwjgl3 : but when running game i am getting this error
I forced to use AMD using DRI_PRIME=1 command but Error happens again. Edit : I also tested on java 9 but the problem happened again. |
|
Also I tested on Windows and everything works OK in windows using lwjgl 3.0.0. |
Updating from LWJGL 3.0.0 to 3.1.0 is not trivial because of the new modular architecture. The error above is likely caused by a mismatch between the Java and native libraries. Try running with
It will be very hard to diagnose this issue without more details. The simplest thing you could do is try to reproduce the issue with just LWJGL code, not via jME. |
|
Just found that when i disable Groovy Glass Style on game GUI (which uses groovy-all.jar) that error happens just occasionally and it runs fine most of the time.
What version for natives library matches with lwjgl 3.1.0 then? If i set 3.1.0 for natives it can not find jars for this reason i set 3.0.0. |
Never mind. I can see your new download page do generate gradle snippet automatically. That's very cool. |
|
Okay, I could build successfully with 3.1.0. when i ran the game for the first time after build, setting groovy glass style on, it ran like a charm but when i closed and reopened it failed with same error. |
|
It sounds like it's a jME or groovy issue then. I have experience with neither, you probably need someone with good knowledge of jME internals to figure out what is going on. I can only guess and my suspicion lies with threading. Does loading groovy or running groovy scripts require new threads to be spawned? You can check yourself with |
|
@Spasi sorry for late reply ... |
|
Hey everyone, I wondered if there is any news on this topic, besides @Ali-RS managed to avoid the problem.
Before the actual game built with OpenGL 3.2 I have a small resolution picker dialog written in Java-Swing. Then after some time the game crashes with the following command line output: If I omit the picker dialog and set the resolution hard coded, everything works fine. Is there anything I can do? I didn't have the problem with the same project and LWJGL 2.9.3 Thank you very much for your great work in LWJGL! |
|
The proper fix for this is to not use AWT/Swing for the dialog. The second best choice is to use a different process for the dialog (launch VM -> show dialog -> launch another VM -> run LWJGL application in the new VM). Even if a workaround for the X error is found, using AWT/Swing + GLFW in the same process is simply not possible on macOS. Which is a major issue, unless you only care about Linux/Windows. For the X error itself, I still think it's an issue with AWT/Swing and not related to GLFW at all. If someone could prepare an MCVE, I'll try to find what's causing it exactly. Two random things you could try, after discarding the dialog and before calling
long display = X11.nXOpenDisplay(NULL);
if (display != NULL) {
System.out.println("Opened display: " + display);
try (SharedLibrary libX11 = Library.loadNative("X11")) {
long XSync = libX11.getFunctionAddress("XSync");
if (XSync != NULL) {
System.out.println("Found XSync: " + XSync);
int ret = JNI.invokePI(XSync, display, 0); // try 1 too if 0 doesn't help
System.out.println("XSync returned: " + ret);
}
X11.XCloseDisplay(display);
}
} |
|
Thanks for the quick anwer! Okay, this means I could replace the resolution picker with a e.g. FX variant? |
|
I don't know about the X error, but JavaFX and GLFW are in the same way incompatible on macOS. |
|
I see... Is this something which is worked on, or a situation which can't be fixed? I think about the engines and editors (JMonkeyEngine) mixing a UI (Swing/FX) with LWJGL 3. I migrated my own level editor from Swing to FX first, and then switched from LWJGL 2 to 3. No problems so far, but I didn't run it on a Mac yet. (my new JavaFX resolution picker doesn't crash the game btw.) |
I'm currently facing a very weird issue: In one of my projects I'm getting the following error during initialization. My initialization code is pretty much identical to the Pong example code, with added logging statements to see the steps of the initialization:
The reason for the vague statement "during initialization" is that the error seems to be asynchronous, and it is not always happening in
glfwCreateWindow. For instance, this is output of another run, where I somehow made it past theglfwCreateWindow:Note that the error in this case also comes with an additional
pure virtual method called, which is not the case when it happens in other places.Another example: If I don't call
glfwInitright at the start of the main function, the error always seems to be triggered byglfwInititself, i.e., I do not get to the point of setting the error callback etc. I was actually very surprised to see that the behavior changes depending on whether I placeglfwInitbefore or after the other initialization code, because this other code has nothing to do with OpenGL / native libraries and just initializes a few Java/Scala data structures.I do get this error with both the latest stable build (build #3.0.0b build 64) and the latest nightly (build #3.0.0 build 41). My system is an Ubuntu 14.04, 64bit, Java 1.8.0_74, Nvidia Geforce GTX 670, Nvidia driver version 352.79.
What makes this issue even more annoying is the fact that it seems to be difficult to reproduce: So far, I get this error only in my main project. I was trying to come up with a minimal example to reproduce it, but in the minimal example the exact same code works. I'm currently trying to add some complexity from the big project to the minimal example to see what may trigger the problem. But even after adding all dependencies and using exactly the same JVM options, I could not reproduce the error so far. I'm now looking into other potential side effects...
I should add: I have just ported the big project from LWJGL 2.9.1 to 3.X for the first time. With 2.9.1 everything was working fine.
Any hints what could possibly go wrong would be highly appreciated.
The text was updated successfully, but these errors were encountered: