我正在开发一个由多个“框架”组成的 OpenGL ES 2.0 应用程序（使用 Windows 上的angleproject 进行开发）。
每个框架都是一个独立的应用程序，不应干扰周围的框架。帧是使用 OpenGL ES 2.0 绘制的，由在该帧内运行的代码。
我的第一次尝试是为每个帧分配一个帧缓冲区。但是有一个问题 - OpenGL 的内部状态在绘制一帧时发生了变化，如果下一帧没有全面重置每个已知的 OpenGL 状态，则可能存在副作用。这违背了我的要求，即每一帧都应该被隔离并且不会相互影响。
我的下一个尝试是每帧使用一个上下文。我为每一帧创建了一个独特的上下文。我正在使用共享资源，以便我可以 eglMakeCurrent 到每个帧，将每个渲染到自己的帧缓冲区/纹理，然后 eglMakeCurrent 回到全局，将每个纹理组合到最终屏幕。
这在隔离实例方面做得很好，但是.. eglMakeCurrent非常慢。只需 4 个就可以使渲染屏幕需要一秒钟或更长时间。
我可以采取什么方法？有没有一种方法可以加快上下文切换，或者通过以某种方式保存每帧的 OpenGL 状态来避免上下文切换？
I have a suggestion that may eliminate the overhead of eglMakeCurrent while allowing you to use your current approach.
The concept of current EGLContext is thread-local. I suggest creating all contexts in your process's master thread, then create one thread per context, passing one context to each thread. During each thread's initialization, it will call eglMakeCurrent on the context it owns, and never call eglMakeCurrent again. Hopefully, in ANGLE's implementation, the thread-local storage for contexts is implemented efficiently and does not have unnecessary synchronization overhead.
这里的问题是尝试以通用平台和独立于操作系统的方式执行此操作。如果您选择特定平台，则有很好的解决方案。在 Windows 上，有 wgl 和 glut 库，它们将为您提供多个具有完全独立的 OpenGL 上下文同时运行的窗口。它们被称为窗口，而不是框架。您也可以使用 DirectX 而不是 OpenGL。角度使用 DirectX。在 linux 上，解决方案是 X11 for OpenGL。无论哪种情况，拥有高质量的 OpenGL 驱动程序都至关重要。没有 Intel Extreme 芯片组驱动程序。如果您想在 Android 或 iOS 上执行此操作，则需要不同的解决方案。最近在 Khronos.org OpenGL ES 论坛上有一个关于 Android 案例的帖子。