Why is drawing on JFrame so much slower than on a JPanel?

Question

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.

Answer 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.