OpenGL 窗口管理器 - 多进程合成答案

【问题标题】：OpenGL window manager - multiple process compositingOpenGL 窗口管理器 - 多进程合成
【发布时间】：2014-11-17 20:25:27
【问题描述】：

我想设计一个简单的窗口管理器，能够合成来自多个进程的输出。我的第一个想法是只对独立应用程序使用不同的线程，所以我只使用一个上下文并在应用程序和管理器主线程之间共享它，但再想想这听起来不是一个好主意，因为任何线程崩溃将终止一切。

所以我决定它必须真正支持应用程序的专用进程，但这让我想到了一个问题，即我究竟如何以高性能的方式将来自不同进程的输出拼接在一起。将数据从 GPU 复制到 CPU 以共享系统内存根本不是一种选择。从 OpenGL 并行常见问题解答中可以清楚地看出，不可能使用来自多个进程的一个上下文，除非它是间接导致性能非常低的。

那么，现有的窗口管理器是如何做到的呢？当然，我不希望有任何低层次的细节，只是一般的概念概述。

【问题讨论】：

如果您的平台将句柄暴露在它所绘制的表面上，您可以这样做。 WDDM (Windows Vista+) 提供了一种称为共享句柄的东西来实现此目的，但是为任意进程访问一个句柄并不是您作为最终用户通常能够做的事情（从这个意义上讲，公共 API 提供的最好的东西是DWM“缩略图”）。不过，在其他平台上滚动您自己的合成窗口管理器要容易得多，尤其是 Linux。 您对什么平台感兴趣？
不幸的是，没有标准和可移植的解决方案。窗口合成器求助于使用供应商特定的扩展，通常甚至不直接使用。例如，Wayland 为此依赖 EGL。这是因为渲染在历史上是非常分散的，你有软件渲染，你有硬件加速的 Direct2D、Direct3D、OpenGL……这就是为什么缓冲区共享必须打破不同技术之间的差距。我想能够按标准在 OpenGL 的不同进程之间共享缓冲区会很不错，但没有迹象表明这会很快发生......
@AndonM.Coleman - 我希望有一些更便携的东西，这样它就可以在现有的 windows、linux 和 android 窗口管理器之上运行......

标签： opengl graphics window-managers multiprocess compositing

【解决方案1】：

那么，现有的窗口管理器是如何做到的呢？当然，我不希望有任何低层次的细节，只是一般的概念概述。

在 X11 中有 X11 扩展 GLX_ARB_texture_from_pixmap 和 Render，它们允许将窗口移出屏幕并将窗口的 X11 像素图绑定为 OpenGL 中的纹理。其实现方式的绰号称为 AIGLX（加速间接 GLX），尽管名称不依赖于间接 GLX 上下文。在这种情况下，间接意味着一切都发生在显示服务器上。

您的合成窗口管理器将从直接与其他进程对话。相反，它只是使用 X11 服务器中已经存在的资源和数据来合成最终结果。

这与 Wayland 不同，Wayland 中的合成器确实直接与其他进程对话以交换帧缓冲区信息。我个人更喜欢 X11 型号，但这只是我的看法。

【讨论】：

我读到 X 是臃肿的、过于复杂的，而且最重要的是，它负责渲染应用程序，而不是应用程序负责渲染自己。这并不理想，但另一方面它仍然比相应的 M$ windows API 更可用，并且比 Wayland 更受支持。我真的很喜欢 Wayland BTW，但在这一点上它看起来不太好用，如果我理解正确的话，它只适用于性能仍然严重缺乏专有驱动程序 blob 的“开源”驱动程序，这可悲的是不急于支持WL
我认为 X 并不臃肿。对于 X 服务器来说，这只是一个可怕的事情。恕我直言，X 渲染应用程序也是一件非常可取的事情。因为当每个应用程序都在渲染自己时，每个应用程序都必须处理所有在显示服务器中愉快地抽象出来的讨厌的细节。恕我直言，Wayland 非常适合作为显示服务器和图形驱动程序之间的后端协议。但恕我直言，它作为前端协议很糟糕。我已经对它进行了试验（在过去的几周里更是如此，因为我的图形延迟较低）。
@user3735658：在我刚刚关闭电源的桌面上，我保存了一个非常有说明性的屏幕截图，为什么应用程序应该只获得对显示系统的抽象访问权而不是自己渲染它们的东西：这是一个屏幕截图一个 MPD 客户端，用 GTK 编写，在专辑列表中它设法完全搞乱了亚像素抗锯齿和字体渲染；看起来它试图应用一些缩放变换，但不知何故，这些变换最终会变换已经渲染的图像并将其破坏为错误的子像素。谈到图形应用程序就像小孩子一样。