Turn: Finally figuring out why the Java Desktop program always feels slow

Transferred from: http://my.oschina.net/u/2306127/blog/370495

Finally figuring out why the Java Desktop program always feels slow!
In the sense that both the server and the browser are using scripts and virtual machines, those are not slow, and Java desktop programs always feel unresponsive? There are two main reasons, one is that the server and the browser are asynchronous, submitted to the rendering out there is enough time to deal with, and the network IO is much slower than the local CPU calls, and the second is that the browser interface is not JavaScript rendering (many people may think that HTML is JS drawing), Instead, browsers natively support the operating system layer, and even do special optimizations.
Java drawing is actually two tiers, one layer is based on the underlying drawing API for bridging, such as swing, such as the Javastyle UI, each UI drawing operation to invoke the virtual machine API, efficiency is difficult to improve The second layer uses the GUI object layer API bridging (such as the WinForm API, but not portable), which reduces the Java calls of many graphical APIs, with performance comparable to native programs. The implementation of PYQT is based on the second approach, so although Python is not efficient, there is no pressure to draw real-time graphics and GUIs. Java's OpenGL is also implemented in the second way, so it is also possible to draw three-dimensional graphics smoothly (if the computational volume is large).

Therefore, the key to improving the interactivity of desktop programs in Java is to use native libraries for GUI-level drawing, which is a lot, including WXWINDOW/GTK/QT, and the effect is very cool. Sublime/blender are used in this mode, many of the programs are Python, but the interface and graphics drawing operations are C + +, call the native operating system API to draw (Qt is called the GUI layer, using different operating systems to draw their own GUI).

Java Desktop Program development recommendations using the Eclipse framework, the development of compatibility is better, plug-in mechanism is relatively perfect. But the Eclipse interface also has the above problem, in the virtual machine response too slow, I have basically given up.

The latest UI systems are directly mapped with OpenGL, with good performance and portability, and needless to say.

Turn: Finally figuring out why the Java Desktop program always feels slow