Java 当Graphics2D.fill（）在SWT中的工作速度慢10倍时？

我正在调查这个问题，当

Piccolo2D

图形在

SWT

桥接器内工作时，速度要慢得多

最后我发现，工作速度慢得多的代码是对方法的调用。在SWT桥的情况下，它的工作速度是普通摆动桥的10倍

可能的原因是剪切区域

还有什么其他可能的原因

---

怎么可能看出，原因是剪贴呢？

Graphics2D.getClipBounds（）的结果在这两种情况下都是相同的，但它被记录为“用户”剪辑区域。有可能看到“设备”剪辑区吗？
SWT比Swing慢，因为它使用了代理到操作系统的小部件。问题是操作系统部分（非托管代码）经常与Java代码（托管代码）通信。这种“转换”（从托管到非托管，反之亦然）很慢，因为JVM必须在系统上设置标志来说明程序是否可以访问（内存，…）

而Swing主要停留在“托管代码”部分，因此可以从JIT优化中获益

另一方面，SWT小部件给人一种更好的感觉，因为操作系统管理绘图、悬停状态等，即使Java代码有点滞后

尽管如此，Piccolo2D使用轻量级小部件，因此不具备SWT的任何优势：-（
在Swing的渲染管道中，Java 7在OpenGL路径上做了大量工作。我猜SWT与Win32 GDI或其他不利用硬件的windows图形界面进行对话。当然，对于硬件渲染原语与软件渲染原语，系数10是一个很容易看到的比率。如何确保它？p.S.我是在SWT+Swing组合中看不到这一点，但只有使用三个组件SWT+Swing+Piccolo2d，您才能编写自己的填充函数。我认为这是因为该函数具有递归回调。SWT很重。它直接将许多绘图操作委托给硬件。我在尝试绘制Buff时遇到了类似的问题eredImages。