问题标签 [egl]

我正在android 4.2上开发一个movieplayer，现在面临一个问题，如何将surfaceview旋转90度，surfaceview用于渲染解码视频，与常用的不同之处在于，我通过“windowManager”将surfaceview添加为系统视图.addView(mysurfacetview)" 在服务中，所以surfaceview 有能力浮动在桌面上。

每当用户想要横向全屏视图时，我的临时解决方案是启动一个在 xml 中预定义 LANDSCAPE 的活动，这将触发服务的 onConfigurationChanged，然后我使用“windowManager.updateViewLayout”触发surfacechanged，最后将surfaceview 调整为全屏大小。

有没有更好的解决方案来旋转surfaceview？我使用了附加到surfaceview的egl，是否可以从egl旋转？谢谢！

我正在编写一个特定的 OpenGL 应用程序，我特别想在其中逐步绘制帧。为此，我想禁用我理解的缓冲区的自动清除，这是GLSurfaceView.Renderer#onDrawFrame(). 有人可以帮助我如何做到这一点吗？我需要用 Java 编写应用程序，而不是使用本机 SDK。

我知道我可以通过以下方式做到这一点：-

1. 在执行时设置属性EGL_SWAP_BEHAVIOR_PRESERVED_BIT位，并且EGL_SURFACE_TYPEeglChooseConfig
2. 通过调用EGLSurface 对象来设置EGL_SWAP_BEHAVIOR属性EGL_BUFFER_PRESERVEDeglSurfaceAttrib

但是，我从 Khronos 文档中收集到：-

• EGL_SWAP_BEHAVIOR_PRESERVED_BIT仅当 EGL 版本为 1.4 或更高版本时才受支持。
• EGL_SWAP_BEHAVIOR仅当 EGL 版本为 1.2 或更高版本时才受支持。

现在，我知道我可以在我的 Android 应用程序中以两种方式访问​​ EGL：-

1. EGL10使用包中 的 Khronos API 类javax.microedition.khronos.egl（EGL11似乎还没有实现）
2. EGL14在中使用 Android API 类android.opengl package（类似于使用类android.opengl.GLES20）

(1) 的问题是版本小于 1.4，所以它不支持我需要的功能。(2) 的问题是，当我在 EGL14 中调用任何方法时，我的应用程序就会崩溃，而且我不确定我应该如何使用它（我找不到一个关于 EGL14 的示例程序/教程应该在应用程序中使用）。特别是，我想学习如何从 EGL14 获取有效的 GL 上下文：在 EGL10 的情况下，我可以通过调用javax.microedition.khronos.egl.EGLContext.getGL(). 但是，我在 class 中没有看到等效的方法android.opengl.EGLContext。事实上，android.opengl除了 EGL14 之外，所有与 EGL 相关的类似乎大部分都是空的。

我最好的选择是遵循与 GLES20 相同的推理方式：仅在方法内部调用GLSurfaceView.Renderer方法：onDrawFrame(), onSurfaceCreated(), onSurfaceChanged()，因为它们提供有效的 GL (GL10) 和 EGL (EGLConfig) 上下文作为参数。所以我在里面放了以下代码onDrawFrame()：-

我相信我不必在调用上述方法之前实例化 EGL14，因为所有方法都是静态的。但是，调用EGL14.eglGetDisplay()会使应用程序崩溃。

任何帮助将不胜感激，谢谢:)

看起来 EGL 将成为将“GUI 窗口”连接到图形服务器的下一个最流行的标准，我的问题是：有一个 GUI 框架，可能在 C++ 中，它能够在 EGL 之上创建小部件和一个漂亮的 GUI ?

由于不同的原因，我排除了 GTK、QT、Wx，它们也不符合我在这里的要求。

我已成功将 GTK 使用的 cairo 后端更改为 GLES（在 X11 窗口实现中）。我为每个 gdkwindow 使用 eglWIndowSurface。我面临的问题是，因为 GTK 正在进行差异渲染，我只能看到渲染的当前焦点区域。有什么方法可以让 GTK 一直渲染完整的窗口？

我尝试使用此指令创建 Android GraphicBuffer

新的 GraphicBuffer(160, 98, HAL_PIXEL_FORMAT_YV12, GraphicBuffer::USAGE_HW_TEXTURE | GraphicBuffer::USAGE_SW_WRITE_RARELY)

它适用于我的 Android 4.0 设备 Huawei Mediapad，但不适用于 Android 2.3 HTC Desire。那就是我得到错误：

05-28 16:53:15.994: W/GraphicBufferAllocator(3765): alloc(160, 98, 842094169, 00000120, ...) 失败 -22 (无效参数)

如果我将像素格式从 HAL_PIXEL_FORMAT_YV12 更改为 HAL_PIXEL_FORMAT_RGB_565，那么它在我的两个设备上都可以正常工作。我想 Android 2.3 不支持 YV12 但无论如何我都需要 YUV 像素的格式。

在 OpenGl ES 2.0“surfaceless_context”的新扩展中，它给出了以下内容：

如果上下文不支持在没有读取和绘制表面的情况下进行绑定，并且两者都是 EGL_NO_SURFACE，则会生成 EGL_BAD_MATCH 错误。

我无法创建这样的上下文。我尝试共享上下文，但没有运气。

链接：http ://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_surfaceless_context.txt

I'm having the following situation:

In a cross platform rendering library for iOS and Android (written in c(++)), i have two threads that each need their own EGLContext: Thread A is the main thread; it renders to the Window. Thread B is a generator thread, that does various calculations and renders the results into textures that are later used by thread A.

Since i can't use EGL on iOS, the library uses function pointers to static Obj.-C functions to create a new context and set it current. This already works, i create the context for thread A using

The context for thread B is created using

I can then set either of the two current:

To use the same logic (function pointers passed to the library) on Android, i want to do this in the C side of the JNI bindings, this time using real EGL instead of Apple's EAGL. I can easily create contextA using a WindowSurface and the native Window, i can create contextB and pass contextA to the shareContext parameter of the eglCreateContext call.

But when i want to make contextB current, i have to pass a surface to the eglMakeCurrent call, and i'm trying to figure out what kind of surface to pass there.

• I cannot use the WindowSurface i use for contextA as the spec says in section 3.7 that "At most one context for each supported client API may be current to a particular thread at a given time, and at most one context may be bound to a particular surface at a given time."
• I cannot specify EGL_NO_SURFACE, because that would result in an EGL_BAD_MATCH error in the eglMakeCurrent call.
• It seems I could use a PBuffer surface, but I hesitate because I'd have to specify the width and height when I create such a surface, and thread B might want to create textures of different sizes. In addition to that, the "OpenGL ES 2.0 Programming Guide" by Munshi, Ginsburg, and Shreiner states in section 3.8 that "Pbuffers are most often used for generating texture maps. If all you want to do is render to a texture, we recommend using framebuffer objects [...] instead of pbuffers because they are more efficient", which is exactly what i want to do in thread B.

I don't understand what Munshi, Ginsurg and Shreiner mean by that sentence, how would a framebuffer object be a replacement for a pbuffer surface? What if I create a very small (say 1x1px) pbuffer surface to make the context current - can i then still render into arbitrarily large FBOs? Are there any other possibilities I'm not yet aware of?

Thanks a lot for your help!

我需要在一个线程中创建纹理并在另一个线程中使用它。我尝试使用共享上下文，但纹理似乎没有共享。我尝试使用eglCreateImageKHR此 示例（Wiktor 发布的代码）

eglCreateImageKHR正在回归EGL_NO_IMAGE_KHR。

此外，在使用我必须定义的扩展#define EGL_EGLEXT_PROTOTYPES之前 #define GL_GLEXT_PROTOTYPES，包括 eglext.h 和 gl2ext.h 来编译代码。这是错的吗？这些是否应该在其他标题中定义？

如果有帮助，这是我创建纹理的线程的代码。我认为我做错的是将OpenGL返回的纹理句柄传递给eglCreateImageKHR并将其转换为EGLClientBuffer. （另外我也不知道reinterpret_cast是做什么的，只是从样本中复制过来的。但是样本对这部分不是很清楚。）

我正在运行的项目使用 CodeJock - ToolKitPro (MFC) 来提供用户界面，并使用其他库在某些窗口中进行一些非常密集的渲染。

我们使用 PVRVFrame 库 (OpenGL) 进行渲染。

当我点击第一个 OpenGL 函数调用时 - 它恰好是eglGetDisplay，但是来自这些库的任何函数调用似乎都会导致相同的错误 - 我收到以下错误消息：

运行时检查失败 #0 - ESP 的值未在函数调用中正确保存。这通常是调用使用一种调用约定声明的函数和使用另一种调用约定声明的函数指针的结果。

我已经读过这是一个问题，该函数是使用某种调用约定（在本例中为 __stdcall ）声明的，但使用不同的约定调用 - 但是我不确定这怎么可能。

编辑：事实证明这是正确的，希望它仍然可以帮助其他有类似问题的人。

在 OpenGL ES 2.0（使用 EGL）中设置深度测试管道时，我是否遗漏了一部分？

我发现了很多关于此的问题，但所有问题都通过在上下文初始化时正确设置深度缓冲区来解决：

或者通过正确启用和清除深度缓冲区，并在上下文初始化后这样做：

注释掉glEnable(GL_DEPTH_TEST)我有一个场景，但没有我想要的深度测试遮挡。

在着色器中，输出视觉上的z组件gl_Position按预期工作（z值在 [0, 1] 范围内）：

正如预期的那样，所有物体都是纯绿色的阴影，越近越暗，越远越亮。可悲的是，一些更远（更亮）的物体被绘制在更近（更暗）的物体上。

有什么我想念的想法吗？（如果没有别的，我希望这总结了其他人一直存在的一些问题）。