为什么在JFrame上绘制比在JPanel上慢得多？

Question

我的问题是为什么在JPanel上绘图时，相比直接在JFrame上绘制相同的swing定制绘画例程快近16倍？它只是双缓冲？它不可能，当然？

背景：当JFrame没有被遮挡时（特别是只有部分遮挡），我有一个自定义绘画未刷新的问题。在搜索完毕后，我决定咬紧牙关，想出如何将JPanel的一个子类连接到bluddy-NetBeans形式的设计器表单中。

对于处于同一情况的任何人：在NetBeans中，您需要创建一个新的标准类（而不是JPanel表单），并且手动对所有内容进行编码（无GUI设计器，天，叹了口气）。然后你添加一个标准的JPanel到你的表单中，设置它的大小;然后右键单击并选择“自定义代码”，然后在组合框中选择“自定义创建”......它将创建一个新的javax.swing.JPanel替换其子类。

所以...这让我“正确地做到”并在组件上绘画，而不是直接在窗体上绘画。此外，面板 - 按键 - 监听器是一个比hi-jacking frames key-event-dispatcher更方便的解决方案。

无论如何，现在profiler说完全相同的自定义绘制代码在JPanel的paintComponent（）中执行的速度比相同的JFrame的paint（）快近16倍......我想知道是否有人能解释为什么。

预先感谢您。基思。

---

编辑：这个问题是基于误解的指标。 profiler不包括/报告JPanel的paintComponent（）方法在AWT-EventQueue线程中，因为我的基线配置文件包含JFrame的paint（）。在问一个愚蠢的问题之前，我应该仔细看看。我的错。

Answer 1

“Swing使用Java2D API进行绘制，并且根据此Java SE 7故障排除指南，Java2D使用一组渲染管线，”它可以粗略定义为渲染基元的不同方式“。 Java2D渲染管道似乎将跨平台Java代码连接到可能支持硬件加速的本机图形库（OpenGL，X11，D3D，DirectDraw，GDI）。在Java 1.6.0_10（aka 6u10）中，“完全硬件加速的图形管道“基于Direct3D被添加到Java2D for Windows，以提高Swing和Java2D应用程序的渲染性能（默认启用）

默认情况下，当在Windows系统上使用Java2D时，默认启用Direct3D管道和DirectDraw/GDI管道（我假设它们各自用于不同的事情）。“

往下看：First call to JFrame constructor takes a long time during Swing application startup (because of java.awt.Window())

Answer 2

的JFrame是一个顶级容器延伸aw.Frame是绘制，而一个JPanel需要原生资源是由UI线程本身呈现Swing组件。