我想知道创建一个负责渲染所有应用程序元素的“系统”范围的渲染服务器是否是个好主意。目前，应用程序通常有自己的上下文，这意味着任何数据在不同应用程序中可能相同，它将在 GPU 内存中复制，并且更频繁的资源管理调用只会减少可用渲染调用的数量。据我了解，OpenGL 执行引擎/服务器本身在设计上是顺序/单线程的。所以从技术上讲，所有可能在应用程序中重用的东西，尤其是像位图或文本和 UI 的几何缓存这样的繁重的东西，只是因为不必要的传输和内存使用而阻塞了服务器。
跨多个应用程序共享场景图有什么缺点吗？自然，假设正确处理意外冻结的客户端。
我想知道创建一个负责渲染所有应用程序元素的“系统”范围的渲染服务器是否是个好主意。
这取决于手头的任务。一个小弯路：以网络浏览器为例，JavaScript 对 DOM 进行操作；CSS 变换和 SVG 元素定义图形元素。响应事件而调用的每个 JavaScript 都可以作为单独的线程/轻量级进程运行。从某种意义上说，网络浏览器是一大堆应用程序的渲染引擎（哎呀，它们在内部甚至被称为渲染引擎）。
为此，这是一个好主意。
总的来说，显示服务器是一件非常好的事情。看看 X11，它有着令人难以置信的记录。这些天 Wayland 是所有的炒作，很多人喝了 Kool-Aid，但你实际上想要一个显示服务器的抽象。然而，不是你想的那样。拥有显示服务器的主要原因是避免冗余代码（不是冗余数据），并且只有一个实体来处理脏细节（颜色空间、设备物理属性）并提供优化的高阶绘图图元。
目前，应用程序通常有自己的上下文，这意味着任何数据在不同的应用程序中可能是相同的，
所以？内存很便宜。而且您不会通过合并重复数据来获得性能，因为对性能而言唯一重要的是处理这些数据所需的内存带宽。但是该带宽不会改变，因为它仅取决于数据的内部结构，但是通过合并不会改变。
事实上，重复数据删除会产生大量开销，因为当一个应用程序进行更改时，不会影响另一个应用程序，必须调用写时复制操作，这不是免费的，通常意味着完整的副本，然而，这意味着虽然使整个副本消耗内存带宽。
然而，对于一个应用程序的数据中的一个小的、选定的更改，每个应用程序都有自己的副本，内存总线被阻塞的时间要短得多。
它将在 GPU 内存中复制，更频繁的资源管理调用只会减少可用渲染调用的数量。
资源管理和渲染通常不会相互干扰。当 GPU 忙于将标量值转换为点、线和三角形时，CPU 上的驱动程序可以做家务。事实上，通过在 GPU 忙于渲染时让 CPU 继续执行与渲染无关的工作，可以获得很多性能。
据我了解，OpenGL 执行引擎/服务器本身在设计上是顺序/单线程的
你在哪里读到的？在 OpenGL 规范中对此没有这样的约束/要求，并且真正的 OpenGL 实现（=驱动程序）可以随意并行化。
只是用不必要的传输和内存使用阻塞服务器。
当数据被加载时，传输只发生一次。重复数据删除不会改变内存带宽消耗。现在内存太便宜了，重复数据删除根本不值得付出努力。
跨多个应用程序共享场景图有什么缺点吗？自然，假设正确处理意外冻结的客户端。
我认为你完全误解了 OpenGL 的本质。OpenGL 不是场景图。没有场景，OpenGL中有mo模型。每个应用程序都有自己的数据布局，最终这些数据被传递到 OpenGL 以将像素绘制到屏幕上。
然而，对于 OpenGL，只有绘图命令可以将标量值数组转换为屏幕上的点、线和三角形。没有什么了。