用于OpenGL ES 2.0的基于SWIG的Java接口和用于SWT的EGL

我计划使用SWIG接口OpenGLES2.0公开的本机API

我知道有JOGL，但不知为什么它有太多的抽象、类和代码

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

关于EGL，我只需要提取java窗口的currentwindow句柄并将其传递给EGL，这样行吗

---

有人已经尝试过了吗？或者它不像看上去那么简单（这就是我们必须使用JOGL的原因）？

基本形式的JOGL几乎只是OpenGL界面上的一个薄包装

在包装器中，事情变得更复杂的地方是当您开始查看缓冲区时。在C OpenGL界面中，所有这些都由

void*

处理。在Java中，这一点都没有意义——Java最接近的对象是

对象

，但不能以这种方式使用

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

在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维护一个保存GL状态的GLContext。对于一个简单的包装器来说，实际上并不需要这种抽象。对于像ShaderProgram这样的抽象也是如此。为什么我们不能简单地用一个直接的API一对一映射的包装器，这样开发人员就不必学习JOGL，如果他已经知道的话OpenGL@seahorse-在Windows和X11上，映射到它的实际工作方式-您有一个上下文（来自WGL或GLX），您所做的一切都与之关联。JOGL设置是有意义的，因为它a）是平台独立的，b）Java不是C