为什么要使用 JNI 在 AWT 的 Canvas 上绘画？答案

【问题标题】：Why would you use JNI to paint on AWT's Canvas?为什么要使用 JNI 在 AWT 的 Canvas 上绘画？
【发布时间】：2014-09-07 17:42:12
【问题描述】：

我对 JNI 很陌生，在研究 JNI 时偶然发现了这一点：

native code 不仅可以与 Java 接口，还可以在 Java Canvas 上绘制，这可以通过 Java AWT Native Interface 实现

是否有特定原因使此功能成为特定/可用？它是否提高了 Windows 系统上的处理时间？请详细说明为什么以及何时使用这样的功能

【问题讨论】：

标签： java java-native-interface java-canvas

【解决方案1】：

Java 中的原生性能渲染...首先想到的是游戏，但真正绘制任何计算密集型或需要高帧速率的东西都会受益。

Official Java Explanation：

从本机代码库直接绘制到 Java Canvas 的能力对于计划将遗留软件系统迁移到 Java 的开发人员非常有用，尤其是包含高性能渲染引擎的系统。它使分阶段迁移变得更加容易，只保留对性能敏感的渲染代码，而将其他不太敏感的代码部分转换为 Java。结果可以是一个以 Java 为中心的现代应用程序，提供可移植性和开发效率的好处，但不会牺牲对关键本机代码性能的投资。

【讨论】：

【解决方案2】：

AWT 的 JNI 绘制最常见的用途是使用 OpenGL 或 DirectX D3D 进行 3D 绘制。一些 java 3D API，如 Java3D 和 JOGL 的初始版本，使用 Canvas.java 作为绘图表面。它也可用于 2D 原生渲染，但 Java 绘图功能足以完成此任务。

【讨论】：

Java3D 1.7.0 将提供其他选项，其 Canvas3D 直接扩展 java.awt.Canvas。 JOGL 在底层使用 JAWT，除了 NEWT，只有它的重量级 AWT GLCanvas 仍然扩展 java.awt.Canvas。 Java AWT 本机接口用于在本机代码中提供与 AWT 的良好互操作性，但只有 Java 绑定（如 JOGL）才能直接使用它，在场景图 API 中执行它是一个坏主意，艰苦的工作已经完成JOGL 以及当 API 过于依赖 AWT 时，很难使其与无 AWT 的 JRE 一起工作。我不相信官方的解释。
我认为 java.awt.Canvas 对于渲染和事件处理的 AWT 线程过于妥协。这就是为什么它需要锁定/解锁 JNI 绘图。将 JAVA3D 与它自己的专有画布一起使用，这听起来不错。缺点是无法将其包含在传统的 2D GUI 中，除非使用屏幕外渲染器。
实际上，通过使用NewtCanvasAWT，可以同时与AWT交互并使用NEWT，无需离屏渲染，两全其美：)