While java programs are platform independent, the JVM itself is platform dependent. I am interested in knowing how Java draws the application GUI (buttons and text) on the screen.
Under Windows, control objects such as buttons are usually created using a window(from user32.dll) or a rectangular region(from gdi32.dll), text is drawn later to the corresponding window/region handle using the provided user32/gdi32 text draw functions.
I tried running a simple two button Java gui application using swing and hooking the majority of create region/window and text draw functions from gdi32.dll and user32.dll, but so far, it seems the Java program is just using these native dlls for drawing the main window frame only.
Does Java.exe uses some other dlls to draw buttons and other controls on the screen ? And if so, why is this case when there are already available native dlls for drawing ?
On Windows Java2D uses Direct3D renderer to draw primitives by default. You may disable it by specifying -Dsun.java2d.d3d=false. In this case GDI renderer will be used.
Add -Dsun.java2d.trace=log,verbose option to trace which Java2D primitives are called in your Swing application.
From the Wikipedia Article:
Unlike AWT components, Swing components are not implemented by platform-specific code. Instead, they are written entirely in Java and therefore are platform-independent. The term "lightweight" is used to describe such an element.
Related
I'm looking for a really simple widget: tree view on the left pane, folder contents on the right, switchable between icons, thumbnails, or detail view. Basically a functional (not pixel for pixel) emulation of Windows File Explorer, but within the Java app. How to do this using only built-in Java libraries? Or a very lightweight framework?
NOT A DUPLICATE
My question is different from the above and I now realize it's a little harder to explain than I initially expected. Two clarifications:
My question is not about a File Chooser. I'm asking about a File Explorer type of dialog. The difference is that a File Chooser is really focused on one task, choosing a file. A File Explorer is a little less focused, and lets the user browse around without a clear objective.
My question is not about native operating system UI / L&F emulation. At all. I'm asking about the basic capability to display the contents of the filesystem using icons and thumbnails. The style and borders etc are not part of my question.
EDIT
I'm looking for something like this
Notice how it's different from this (JFileChooser)
JFileChooser will do that if you are wanting something built in to Java.
https://docs.oracle.com/javase/7/docs/api/javax/swing/JFileChooser.html
If you are not using Swing but SWT (like Eclipse) you can use SWT FileDialog
You could use the AWT library to customly render the entirety of Explorer. Whilst the only hard part about this is correctly using layout managers to get components exactly where you want them and adding event listeners for each button, using AWT wouldn't make it look like Explorer on different operating systems because AWT uses the native system components.
You could check if the OS is not Windows and then use Swing if it isn't. In that case, you'd have to retexture every single used component such that its look and feel is the same as your targeted Windows version. Even if you did that, you'd still have to somehow change the JFrame's look and feel, which is possible using dark magic, but quite obscur. You can do this in a very quirky way, just setUndecorated(true) and manipulate the JFrame's boundaries until it lets you draw outside the JFrame, so that you can draw the Windows' decoration around it without resizing the Window. On top of that, you'd also have to check if it's maximised, as maximized windows don't quite look the same in Windows.
To cut things short, just use JFileChooser if you just want to allow the user to select one or multiple files. There isn't really any point in recreating Explorer, but if that's what you want to do, I'm not stopping you.
I'm developing a JavaFX Application, In here, the outer elements of the JavaFX Window Changes across different Operating System's, i.e. The Position of Close, Minimize and Maximize Window is on left on Mac OS X and on the right in the Windows, Also there Shapes are Different as The OS Changes.
Also if the Application is Running Under OS X, it has drop shadow effect along the boundaries, which in case of Windows is Not Present :
And Want My JavaFX Application to look exactly the Same, Regardless of Operating System, it is Being Run On. How Can i Achieve this ?
Use the undecorator project.
Decorate undecorated JavaFX stages with custom skin. This helper brings a custom look to your JavaFX stages.
See also:
JavaFX entirely customized windows?
I know why these components are called heavyweight components. What I'm really interested in is why they were not implemented as lightweight. Thanks
These components are windows of different kind. If you want to create a window in the operationg system you need to call some OS native code, because there is no way to do it in Java. More than that, all the user input events (mouse, keyboard, etc) are dispatched by the OS to the appropriate OS window. Java components listen to these events in the native code and send them to the java level via JNI. To sum up: it is just impossible to do them lightweight.
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