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