9

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.

corlettk
  • 13,288
  • 7
  • 38
  • 52
  • The profiler, VisualVM iirc, should tell you which method(s) is taking more time. That would be a good start to find what's going on. – Jonathan Drapeau Aug 16 '13 at 12:32
  • 1
    @JonathanDrapeau: You're right! The profile is NOT reporting paintComponent as part of the "AWT-Event-Queue" thread (whereas JFrame paint was)! So it's a difference in how the two solutions are reported. My bad! – corlettk Aug 16 '13 at 12:42
  • this is very specifics question, because paitning to AWT Components would be faster (peers from native os) as for its childs Swing JComponents, but already we talking about prehistorics Graphical core, there no place something speedee ot optimalize, you can to compare with a new Graphics core used in Nimbus and the same (AFAIK) with small changes as base for JavaFX – mKorbel Aug 16 '13 at 13:26
  • 1
    +1 for [profiling](http://stackoverflow.com/q/2064427/230513) and sharing your odyssey. If you [answer your own question](http://meta.stackexchange.com/q/17463/163188), you might cite the approach suggested [here](http://stackoverflow.com/a/2561540/230513) on taming the GUI editor. – trashgod Aug 16 '13 at 17:23
  • @trashgod: Thanks. My initial problem was I couldn't figure out how to wire a new subclass of JPanel into an existing NetBeans-GUI-designed JFrame, except to start again again again (sigh) with a non-GUI-designed JFrame... which is not quite the same as adding a subclass of JPanel to a new (empty) non-GUI-designed-JFrame, but thanks for all the fish anyways. Your answer is a really good answer to it's question... and now I know precisely how to do that, if I ever need to. "Using The NetBeans GUI Designer" should be a free eBook (or a wiki). It is NOT a self-explanatory piece of software. – corlettk Aug 17 '13 at 00:22

2 Answers2

1

JFrame is a top level container extending aw.Frame that needs native resources for drawing whereas a JPanel is a swing component that is rendered by the UI thread itself.

vivek
  • 386
  • 3
  • 12
0

"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())

Community
  • 1
  • 1
Stephan Kristyn
  • 15,015
  • 14
  • 88
  • 147
  • Sorry, I don't understand how Direct3D could make painting on JPanel so much faster that a JFrame... and it IS visibly faster, so it's definitely not JUST "bad profiling" on my part. I guess that components could be painted via an accelerator pipeline, while the frame is "raw". It makes some sense given that frames generally just provide a "static background" for the components to render all the "volatile content" over... I just prima-facie expected JFrame to use "the best available" graphics pipeline, even just to be consistent with JComponent. Thanks for your interest. – corlettk Aug 20 '13 at 23:04