My question is WHY is the same swing-custom-painting routine nearly 16 times faster when drawing on a JPanel compared to directly on the JFrame? Is it just double-buffering? It can't be, surely?
Background: I had a problem with the custom-painting not being refreshed when the JFrame was unobscured (especially having been only partially obscured). After searching SO I decided to bite-the-bullet and figure-out how to wire a subclass of JPanel into a bluddy-NetBeans-form-designer form.
For anyone in the same situation: In NetBeans you need to create a new standard class (NOT a JPanel form) that just happens to extend JPanel, and manually code everything there-in (no GUI designer, like the good-ole-days, sigh). Then you add a standard JPanel to your form, set it's size; then right-click and select "Customize code" and select "custom creation" in the combo-box... where it creates a new javax.swing.JPanel substitute your subclass thereof.
So... This allowed me to "do it properly" and paint on a component, instead of directly on the form. Also, the panels-key-listener a much neater solution than hi-jacking the frames key-event-dispatcher.
Anyway, now the profiler says that EXACTLY the same custom-painting-code executes nearly 16 times faster in JPanel's paintComponent() as apposed JFrame's paint()... and I was wondering if anybody could please explain why.
Thank you in advance. Keith.
EDIT: This question is based on MISINTERPRETED METRICS. The profiler does not include/report the JPanel's paintComponent() method in the AWT-EventQueue thread, where-as my baseline profile does include JFrame's paint(). I should have looked more carefully before asking a silly question. My bad.
"Swing uses the Java2D API for drawing, and according to this Java SE 7 troubleshooting guide, Java2D uses a set of rendering pipelines, "which can be roughly defined as different ways of rendering the primitives". More specifically, a Java2D rendering pipeline seems to connect cross-platform Java code to native graphics libraries (OpenGL, X11, D3D, DirectDraw, GDI) that may support hardware acceleration.
In Java 1.6.0_10 (aka 6u10), a "fully hardware accelerated graphics pipeline" based on Direct3D was added to Java2D for Windows to improve rendering performance in Swing and Java2D applications (enabled by default).
By default, when Java2D is used on a Windows system, both this Direct3D pipeline and a DirectDraw/GDI pipeline are enabled by default (I assume they are each being used for different things)."
Read on: First call to JFrame constructor takes a long time during Swing application startup (because of java.awt.Window())