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.).
Related
In Eclipse, I created one CN1 project and one normal Java project, which depends on the former. The latter contains some utilities (e.g., source code generation) and some JUnit tests. I use the following simple hack:
CodenameOneImplementation impl = new JavaSEPort();
Util.setImplementation(impl);
Display.init(impl);
It works, but there's a fullscreen window shown and the program doesn't terminate when main is done. I know, that it's the normal behavior for GUI applications, but I don't need any GUI as I only initialized Display, in order for Display#getResource to work.
How can I get rid of the window (or at least make it small)?
How can I terminate the program without having to call System.exit (i.e., something like running the event handling thread as daemon)?
Is there more to set up?
Use something like this:
JavaSEPort.setDefaultInitTarget(new JPanel());
This would draw the UI of the display into the blank JPanel.
About exiting the app you would need to use System.exit(0) as the EDT loop and native GUI loop are running. You can stop the EDT but that might not work well for the desktop port so just using exit is easy and common practice.
I'm currently trying to develop an JavaFX Application (Game). In order to keep the application run smoothly, I try to lay off as much of the program logic into a separate thread. However, I often stumble into the problem that some JAVAFX API Calls require to be run in JFX Application thread. E.g. creating a set of rectangles and coloring it, can be done in a thread - while adding them to a "Group", calling .doLayout() and .applycss() requires JFX Appl. thread.
I also realized that ".play()" a transition is also required to be run in JFX Application thread.
The problem is - if you are not executing it in the correct thread - an "array out of bounds" exception may occur randomly within JFX which does not point you to the root cause. It always hard to determine whether the program and graphic logic can be offloaded to a thread or is required to be run in JFX Application Thread.
Does anybody know a list of JavaFX method calls which require to be run under JFX Application Thread?
Thanks all!
According to the Application class documentation (and this is also specified in other places in the JavaFX documentation):
Creation of JavaFX Scene and Stage objects as well as modification of scene graph operations to live objects (those objects already attached to a scene) must be done on the JavaFX application thread.
So you can create new nodes (e.g. rectangles) on a background thread, and you can modify their properties (e.g. "color them") on a background thread as long as they have not been attached to a scene. Once the node is attached to a scene, any modification of the node must occur on the FX Application Thread.
If a pane or group is attached to a scene, then calling getChildren().add(...) modifies that pane/group, so it must be performed on the FX Application Thread. The other examples you cite (layout() and applyCSS()) only make sense if the relevant node is attached to a scene anyway.
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.
Coming from a WPF world, I am having a hard time implementing some basic stuff in Java.
I need to execute a *.JAR file from another java GUI application. This JAR file takes minutes to finish, and I want the GUI not to freeze.
So, my initial solution would be: create a SwingWorker class to call a command line in background.
My main concerns are:
I need to get the console output from the *.JAR file and show it in the GUI. Is it possible to update the GUI from a background thread?
Is it possible to cancel the thread from a user input?
How do I get notified that the thread is finished?
Is my solution a good one?
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?