I started working with the new Lwjgl 3 which uses GLFW for its Display/mouse/keyboard handling and I'm really liking it! However today i hit a brick. I had a simple rendering animation going but when I dragged the screen it stopped rendering until i let go again.
According to: http://www.glfw.org/faq.html
The problem arises due to windows.
3.5 - Why does my application freeze when I move or resize the window?
The Windows event loop is blocked by certain actions like dragging or resizing a window, or opening the window menu. This is part of the design of Windows and cannot be changed by GLFW. If you wish to keep rendering during such actions, you should render from a secondary thread.--http://www.glfw.org/faq.html
Ive done multi threaded things before in Java. But im not sure what goes in its own thread for this case. Should I have the opengl code and the GLFW code in seperate threads? I'm also having trouble thinking of a way to word my concerns.
The only real restriction as far as I can find out is that GLFW needs to be in the application's main thread. This is where the OS event queue lives for GLFW and is why glfwPollEvents and glfwWaitEvents need to be in the main thread.
OpenGL rendering can be done from its own thread. glfwMakeContextCurrent ties the OpenGL context to the thread making that call. If your render function runs on it's own thread just make sure to update the context (as shown in the demo).
LWJGL Forum topic: [SOLVED] LWJGL3 Not threading as expected
LWJGL3 Multithreaded Demo referenced in the above link
No, you cannot use GLFW and OpenGL in separate threads. Both must operate in the main thread. As for the blocking, there's not much you can do about it. You'll just have to check for extended pauses between frames, (E.x. when the user moves the window.) and calculate animation, and other time based events accordingly.
Related
Hi I'm working on a group project and the code works on my teammate's PCs but I keep hitting MacOS specific errors. And this time I seem to be stuck (no easily Googleable answer).
In a previous post I discovered I need "-Djava.awt.headless=true" as VM setting to properly run my simulation. Now when I try to spawn in some JFrame they are all met with a lovely "java.awt.HeadlessException" Exception because of that VM flag.
Trying to achieve
I want to be able to spawn those JFrames on my MacBook also.
The problem
I need -Djava.awt.headless to be both true and false at the same time for my program to run properly on Mac. Which if I understand my problem correcly, means I have a big problem on my hands.
EDIT: running it in a VM on my Macbook allowed me to run the project properly. This is far from an ideal fix. I'm still searching for a solution to this obscure problem.
What I tried
not running with the VM option: the problem described in previous post occurs. Thus this is not a viable option
running with the VM option: this throws a -Djava.awt.headless when creating a JFrame.
The best way to fix this may be by going back and solving your original problem a different way.
You must make sure that you are not initializing your BufferedImage in the main thread (GLFW thread), it MUST be done separately. It is hard to tell from your original question, but that looks like part of the cause there. Start a new thread to do the image processing instead.
See my solution and recommendation at the bottom of this answer for a quick summary, and also see here for someone else that had the same issue: Java Creating Instance of BufferedImage Freezes Program
A quick note on why your code works on Windows and not Mac: that is because both OS often run different implementations of openGL, and typically Mac can lag behind and miss out on a bunch of updates/changes that may solve problems like this one so that it doesn’t freeze when initializing a BufferedImage on the openGL thread.
If the above didn’t work then lets first look at what headless mode is. (Emphasis mine):
See link at bottom for full article and more info.
Headless mode is a system configuration in which the display device,
keyboard, or mouse is lacking. Sounds unexpected, but actually you can
perform different operations in this mode, even with graphic data.
Where it is applicable? Let's say that your application repeatedly generates a certain image, for example, a graphical authorization code
that must be changed every time a user logs in to the system. When
creating an image, your application needs neither the display nor the
keyboard. Let's assume now that you have a mainframe or dedicated
server on your project that has no display device, keyboard, or mouse.
The ideal decision is to use this environment's substantial computing
power for the visual as well as the nonvisual features. An image
that was generated in the headless mode system then can be passed to
the headful system for further rendering.
So when should headless mode be used:
On a machine that has no display device, keyboard, or mouse.
That is not you is it? However if that is you (LWJGL?), then lets look at how you can work with headless mode:
An image that was generated in the headless mode system then can be
passed to the headful system for further rendering.
This means that you should have a special piece of headless code that does your headless image stuff, but then passes the image back to a normal JFrame with a head.
So why does it fail for you:
Many components are affected if a display device, keyboard, or mouse
is not supported. An appropriate class constructor throws a
HeadlessException
Button
Checkbox
Choice
Dialog
FileDialog
Frame
Label
List
Menu
MenuBar
MenuItem
PopupMenu
Scrollbar
ScrollPane
TextArea
TextField
Window
Solution to the problem:
some classes, such as Canvas or Panel, can be executed in headless mode.
Perfect, so we just need to be careful what is used in headless mode. You asked how you can both use and not use headless mode, well rather than globally setting headless mode with VM option -Djava.awt.headless you can do it programmatically within your code using System.setProperty("java.awt.headless", "true"); where needed. A JFrame should be normal (not Headless), but you can spawn a JPanel as headless without issue.
I recommend:
You create a normal headed main thread with no VM option that spawns JFrames, and then use that main thread to spawn a new child thread and set your LWJGL bits in that thread to be headless, and that way you can run your LWJGL code without issue, and at the same time you can still have JFrames from your main thread. Remember to make sure that the Buffered image is not done in the main LWJGL/OpenGL thread.
Headless info source:
http://www.oracle.com/technetwork/articles/javase/headless-136834.html
I am trying to Embed a Game Window inside Java JFrame using SetParent. I am using the following kind of Code using Java JNA User32 library.
SetParent(GameWin,JFrameWin);
SetWindowPosF(GameWin,null,Game_X_pos ,Game_Y_pos+1,0,0,0x0020 | 0x0001 | 0x0008);
The above code is working fine and my game window is becoming a part of the JFrame successfully.
But the controls kept in my JFrame like Drop down list and Buttons heavily slow down after doing this process.
Whenever I am clicking any button or dropdown list in my JFrame, it is responding after a lot of time something like after 1 or 2 minutes.
If I don't Embed my game window inside JFrame then everything works fine as usual.
When you make a window from one process be parented by a window of another process you are attaching the message queues of those windows.
The game window likely has a message loop that is quite different from a normal GUI app. Almost certainly this game is not very interested in dispatching your window's queued messages in a timely fashion. The game did not expect to be hijacked in this way.
There's probably not much that you can do to ameliorate this situation. Cross process parenting is something that basically should not be done. More reading on the subject here: http://blogs.msdn.com/b/oldnewthing/archive/2013/04/12/10410454.aspx
For the first time, I'm writing a Java application that is graphics-intensive without a GUI. It generates images by creating a BufferedImage and working with its Graphics2D object. Images are written to files using ImageIO.write.
I need to decide whether to work in the main thread, or the Event Dispatch Thread.
In favor of the EDT, I would do all the graphics updates in the EDT if I were writing a GUI.
In favor of the main thread, the application will compute continuously for the whole time it is running, without any user interaction to break things up.
Which thread for non-GUI graphics?
Non EDT is what I would have guessed (and the way I've always coded it).
But could you confirm, does the app. have a GUI?
No, the app does not have a GUI. It needs to be able to run unattended.
That settles it, forget the EDT & use whatever Thread you like (including the default one given to the app.).
We are calling web services to gather information for a graph with about 1500 nodes. We are displaying the graph in Prefuse while it continually is adding nodes and edges. Most of the time this seems to work great, but every once in awhile the entire app freezes, and the only way to recover is to kill the application and start over. No exceptions are printed out when this happens. On other occasions, I do fairly often see "IllegalArgumentException: Invalid row index: -1", but this doesn't seem to be associated with the freezing of the app.
I saw a related questions about freezing in applets, but our app is running in a JFrame, not an applet. Just in case this was our problem, we tried calling ActivityManager.stopThread() (could not find the kill method) in various places in our code. This doesn't seem to have much if any difference.
Is there a thread safe way for prefuse to display the graph while editing the graph?
Is there a thread safe way to display the graph while editing the graph?
All updates to the GUI must be done on the EDT. Use a SwingWorker.
See Concurrency in Swing for more information.
I've just started making my first GUI application in Java and I decided to use the NetBeans IDE to do it. I think its working fine so far, except for one problem; it seems to be slow updating the content of a window.
Even in very simple windows with few controls I find that when - for example - closing or resizing a window, I get the normal window border working properly but the inside is completely see through for a second.
It's not the biggest deal in the world, I just find it mildly annoying.
EDIT: I've tried the HelloWorldSwing from the official Java tutorial but I have the same issue, only now, when resizing, instead of being transparent, the new area of the window is black until the contents updates.
You should ensure that all of your GUI updates are performed in the Event Dispatch Thread, and that any other long running tasks are performed in worker threads. If you have long running tasks running in the EDT, your GUI will feel sluggish. Take a look at this tutorial for concepts on Swing Threading.
In the absence of any technical problems with your app, this could simply be JVM warmup effects. Do updates speed up if you resize the window a few times?
This could be a Java2D hardware accelleration issue. Is your 3D graphics card driver fully updated?