在两个应用程序之间共享OpenGL帧缓冲区/渲染缓冲区

比方说,我有一个应用程序女巫负责通过OpenGL库在屏幕上绘制的东西。 为了紧密集成的目的,我想让这个应用程序A完成它的工作,但是在一个FBO中或直接在一个渲染缓冲区中进行渲染,并允许一个应用程序B对这个缓冲区拥有只读访问权来处理屏幕上的显示它作为一个2D纹理)。

看来FBO属于OpenGL上下文,上下文在进程之间是不可共享的。我明白,允许几个进程在同一个上下文中是混乱的是邪恶的。 但在我的具体情况下,我认为这是相当安全的,这是合理的

注意:

应用程序A是一个QApplication ,应用程序B是一个native win32

编辑:

渲染大小接近全屏,我想到了一个2048x2048 32bits缓冲区(我现在不使用alpha通道,但为什么不使用后者)。

Solutions Collecting From Web of "在两个应用程序之间共享OpenGL帧缓冲区/渲染缓冲区"

Framebuffer对象不能在OpenGL上下文之间共享,不管它们是否属于同一个进程。 但是纹理可以被共享, 并且纹理可以被用作帧缓冲区对象的颜色缓冲区附件。

在进程之间共享OpenGL上下文,如果图形系统为这个工作提供API,实际上是可能的。 在X11 / GLX的情况下,可以在多个进程之间共享间接渲染上下文。 有可能在Windows中通过一些真正粗暴的黑客行为。 MacOS X,不知道如何做到这一点。

所以最简单的做法是使用像素缓冲区对象来获得对渲染图像的高性能访问。 然后通过共享内存将其发送到另一个应用程序,并将其上传到一个纹理中(再次通过像素缓冲区对象)。

根据我的理解,除非是内核模式对象,否则您将无法共享Windows下进程之间的对象。 即使共享的纹理和上下文也可以创建性能命中,同时它也赋予了同步SwapBuffer()调用的额外责任。 特别是在windows平台下,OpenGL的实现是臭名昭着的。

在我看来,你可以在事件,互斥,窗口消息,管道等进程间通信机制上进行中继来同步渲染。 但是只要意识到在这种方式上接近性能的考虑。 内核模式对象是好的,但每次向内核过渡的时间是100ms。 对于高性能渲染应用来说这是昂贵的。 在我看来,你必须重新考虑多进程渲染设计。