基于 SWIG 的 Java 接口,适用于 OpenGL ES 2.0 和 EGL(适用于 SWT)

发布于 2025-01-06 23:44:32 字数 318 浏览 1 评论 0原文

我计划使用 SWIG 连接 OpenGL ES 2.0 公开的本机 API。

我知道有 JOGL,但不知何故它有太多的抽象、类和代码。

我想要的只是一个非常简单的 Java API 来与 OpenGL ES 2.0 和 EGL 应用程序交互。最后我的应用程序将使用 SWT。 SWIG 可用于使用 OpenGL ES 2.0 和 EGL 公开的 C API 生成 Java 接口。

关于 EGL,我只需提取 java 窗口的当前窗口句柄并将其传递给 EGL,这行得通吗?

有人已经尝试过这个或者它并不像看起来那么简单(这就是我们必须使用 JOGL 的原因)?

I was planning to interface the native API exposed by OpenGL ES 2.0 using SWIG.

I know there is JOGL, but somehow it has too many abstractions, classes and code.

All I want is a very bare minimum and simple Java API to interface with OpenGL ES 2.0 and EGL application. Finally my app will use SWT. SWIG can be used to generate the Java interface using the C API exposed by OpenGL ES 2.0 and EGL.

With regards to EGL I simply have to extract the currentwindow handle of the java window and pass on to EGL, would this work?

Has someone already tried this out or it isnt as simple as it seems(and that is the reason we have to use JOGL)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

忆伤 2025-01-13 23:44:32

JOGL 的基本形式几乎只是 OpenGL 接口的薄包装。

当您开始查看缓冲区时,包装器中的事情变得更加复杂。在 C OpenGL 接口中,这一切都由 void* 处理。在 Java 中,这根本没有意义 - 最接近的 Java 是 Object,但不能以这种方式使用。

...太多的抽象、类和代码。

在 C 语言中,我们说“只需获取这块内存,并将其用作顶点、法线和颜色的交错列表”,我们需要 Java 接口的额外支持,以允许我们灵活、高效地将类似的东西存入内存。我怀疑这是您对大量抽象、类和代码的观察的根源。

在带有 JOGL 的 OpenGL 3.0 中,您可以直接简单地使用已弃用的固定功能立即模式,例如:

gl.glBegin(GL2.GL_QUADS);          
    gl.glColor3f(0.0f, 1.0f, 1.0f);   // set the color of the quad
    gl.glVertex3f(-1.0f, 1.0f, 0.0f);      // Top Left
    gl.glVertex3f( 1.0f, 1.0f, 0.0f);       // Top Right
    gl.glVertex3f( 1.0f,-1.0f, 0.0f);      // Bottom Right
    gl.glVertex3f(-1.0f,-1.0f, 0.0f);     // Bottom Left
gl.glEnd();       

在 OpenGL ES 中,固定功能立即模式渲染内容根本不存在,因为它在运行 OpenGL ES 的设备类型上效率极低。因此,JOGL 与 OpenGL ES 的绑定中剩下的所有函数都需要 Java 中的复杂抽象才能使用,因为它们严重依赖于指向缓冲区的 void* 指针很难在 Java 中有意义地公开。

长话短说 - 如果您编写自己的 Java OpenGL ES 包装器,它不会比 JOGL 简单。 JOGL是 Java 的简单 OpenGL 包装器。

JOGL in its basic form is pretty much just a thin wrapper over the OpenGL interface.

Where things get more complicated in that wrapper is when you start looking at buffers. In the C OpenGL interface that's all handled by void*. In Java that doesn't make sense at all - the closest Java has is Object, but that can't be used in this way.

... too many abstractions, classes and code.

In C where we say "just take this chunk of memory and use it as an interleaved list of vertices, normals and colours" we need extra support on the Java interface to allow us to get something like that into memory flexibly and efficiently. This I suspect is the root of your observation about the large numbers of abstractions, classes and code.

In OpenGL 3.0 with JOGL you can directly and simply use the deprecated fixed functionality immediate mode, e.g.:

gl.glBegin(GL2.GL_QUADS);          
    gl.glColor3f(0.0f, 1.0f, 1.0f);   // set the color of the quad
    gl.glVertex3f(-1.0f, 1.0f, 0.0f);      // Top Left
    gl.glVertex3f( 1.0f, 1.0f, 0.0f);       // Top Right
    gl.glVertex3f( 1.0f,-1.0f, 0.0f);      // Bottom Right
    gl.glVertex3f(-1.0f,-1.0f, 0.0f);     // Bottom Left
gl.glEnd();       

In OpenGL ES that fixed functionality immediate mode rendering stuff just doesn't exist, because it's horrendously inefficient on the types of devices that OpenGL ES runs on. As a result all the functions you're left with in JOGL's bindings to OpenGL ES are the ones that need complex abstractions in Java to be able to use, because they rely heavily on the void* pointers to buffers that are hard to expose meaningfully within Java.

Long story short - if you write your own Java OpenGL ES wrapper it will be no simpler than the JOGL one. JOGL is the simple OpenGL wrapper for Java.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文