I have to create a window transition animation for android (like the one when closing an app. It fades away and another comes in from a corner) on java. I have heard that animating with swing is a bit more complicated than with javafx. So will I face any problems while making programs using only swing or is there anything I cannot do using swing but could do using javafx? I would prefer using swing as I am familiar with it. Thanks.
JavaFx is better to use as it is having better properties.
http://www.dummies.com/how-to/content/10-differences-between-javafx-and-swing.html
Related
I am a Java developer with some expertise in graphical programming but not very skilled with the most recent techniques.
I am developing a Java graphical application using Apache Netbeans IDE 11.2; the application includes many structured panels (split panels, tab controls) and executes 2D drawings on some of them, using Swing and AWT.
The application worked well until now. After the last modifications, I am facing the following problem:
The application properly performs all drawings (polylines, rectangles and so on) on the main panel, but abruptly the panel is cleared and the original background restored, deleting all drawings.
The debugging shows that the clearing is not performed by any statement of the program. So I suppose that it is managed behind the scenes by AWT or something like this.
I understood that Swing automatically implements double buffering (anyway I also inserted a setDoubleBuffered statement), so I made the drawings directly on the screen without using a buffer. On the other hand, this had worked perfectly until now.
My questions are:
How can I detect the event that causes the causes the restore of the background? And how can I prevent this restore?
A solution could be to disable Swing Double Buffering and code it explicitly. I am not sure of this. Any hint?
Thank you very much for any suggestion.
A while ago I wrote an application in Java using Swing for the GUI development. As I want to learn more about JavaFX I'm trying to convert it but I get stuck on one piece of my application I can't seem to find the right equivalent for in JavaFX. In Swing I was able to make a JPanel, create an image, and then rescale the image based on the size of the JPanel using the component events on the panel. Then I'd draw stuff on the image and draw that on the graphics of the JPanel. Also I'd use mouse events on the JPanel to implement zooming and panning on the underlying image.
I'm not sure whether this was good practise in the first place, but it enabled me to draw anything, from pixels to lines to circles to images, on the JPanel, essentially creating sort of a rendered viewport for my application.
What would be the best way to go about this in JavaFX? I've looked at tons of tutorials and youtube videos, but they all seem to focus just on normal GUI controls like buttons, and when I look at game dev for example they make a lot of use of standard JavaFX Nodes to quickly generate moving entities in their scene. I just need sort of a canvas to render stuff on as I please, but if I add something like a default Canvas or Region in the Scene Builder for my FXML file I don't know how to start drawing on that. I'm completely lost in the jungle of tutorials and documentation on the internet.
Does anyone know of any good resource for this kind of application cause I just don't know where to start.
This question might not seem very technical but, out of curiosity,I want to know that:
How does bare/raw Swing code written by me, turn into a wonderful graphical application?
For example:
Like when we make a JFrame visible, or when we place a JButton on it. Who makes it happen? OS or Java or JVM.
Who makes the colors come up?
What is the process going on behind the scenes?
I ask this maybe because its the first time in my life that I made a RealWorld graphical application and these questions popped up in my mind!
Thanks in advance!
In Swing, all the GUI components are written entirely in Java and are rendered using Java. For example, JButtons would be drawn by Java and not by any internal OS stuff. Thus, Swing components are called "light-weight components" because they are managed and rendered by Java instead of by the OS (or any native widget toolkit).
Note that Java also has a toolkit called AWT. Swing is based on nested and inherited methods from AWT, except that it creates native widgets using the OS.
So at some point, Swing will have to create a window on the screen and draw on it. The magic that actually creates the window is handled by AWT. Notice that JFrame extends from java.awt.Frame which means that although JFrame may be rendered mostly by Java, it is backed by a heavy-weight native OS window.
In short, there's an AWT toolkit, which is the layer that does all the window management and drawing. It is calling native platform specific code inside the JVM. It is also responsible for java2d drawing. It can use accelerated directx or opengl pipelines.
Swing is developed on top of it. Swing actually draws every button and every object with plain java code. The drawing is handled to a current look and feels that decide how to draw components. So you can override their paint methods, and add some extra things without any problems.
Metal and Nimus LaF are 100% java2d drawn, so inside of them you will find things like drawRectangle and drawLine to draw components. Native look and feels, like windows, gtk, access current operating systems theme to draw something that looks similar to native widgets. That is why they do not always look like native applications.
There are also other gui toolkits for java, like SWT, used, for example, in Eclipse. What it is doing, is getting the window from the AWT, and then putting 100% native widgets on it. It is much better integrated with the OS, looks better, works faster, uses less memory. But with it, you'd have to distribute your application with os specific native libraries and it is less customizable, compared to Swing.
I don't know all the details, but the actual graphics are displayed/rendered via the swing/awt packages through the JVM itself.
I want to make an application which will have the following:
a jframe (or frame, or whatever) with some java style menus (Jmenu) on the side, and on the other side of the jframe, a OpenGL canvas (which only occupies part of the jframe) and let them integrate together.
meaning, for example, I want to change a slide, and it will change the view of the opengl.
Is it even possible to embed an OpenGL inside a Jframe?
Also, a recomandation for an opengl library that would support such thing. I played a bit with JOGL, but also saw that there are other open-source, and also LWGL and stuff
EDIT:
Added an image from a project made with JOGL which is exactly what I'm after.
A canvas of JOGL inside a Java GUI
for hight Graphics performance is required to use AWT Component exclusively,
I'd suggesting not mixing AWT with Swing
maybe JOGL could be right way, maybe not
I have a Windows Mobile application written in Java that uses AWT for the user interface. I am looking at porting the UI to SWT. I got a hold of the SWT libraries for windows mobile and I started looking at what work will be involved in actually porting it over. I think the first thing I have to decide is how to handle a large number of screens in the application.
In AWT the UI is basically a single java.awt.Frame with CardLayout. Each screen is then just an extension of java.awt.Panel, and is added to the Frame. Then whenever we need to change to a different screen we just set that panel to the top-most.
SWT doesn't have such a layout manager (and I'm not even sure if that is the best/most efficient way of doing it anyway, since the system resources associated with every screen in the application are always held). One way I thought of doing it was that each screen would be its own org.eclipse.swt.widgets.Shell. Switching from one screen to another would involve a display manager class creating the new screen (shell) and disposing of the old one (not sure of the performance hit here of creating the shell and all of the widgets every time the screen is shown?). I am not sure though if having multiple shells in one mobile application is a good idea??
Does anyone have any suggestions on the best way to handle multiple screens in a mobile application using SWT? Is there an equivalent to the method we are currently using in AWT, i.e. CardLayout? Or am I right in thinking that this is not really the best way of doing it, given the use of resources for every screen, even if they are not being displayed?
So the answer to my own question seems to be that there is in fact a StackLayout in SWT, which is pretty much identical to CardLayout in AWT. So I can use that and the job of porting from one to the other is pretty easy because they act in the same way.
Not sure how it would play out in Windows Mobile, but MigLayout is a great layout manager for SWT, which may support the kind of layout you describe.
Check out its demos.