我只是在了解它们，并发现它们已被弃用而令人沮丧。我应该继续投资学习吗？我会学到一些对当前模型有用的东西吗？
答案 0 :(得分：25)
我认为，虽然我可能错了，因为大多数高性能图形应用程序（主要是游戏）几乎只使用顶点缓冲区等（为了挤出卡的每一滴性能），那里压力不再担心显示清单（甚至是古老的glVertex电话）等“轻浮”的物品。恕我直言，这为学习编写OpenGL代码的人提供了一个巨大的障碍，并且（为了我自己的目的）是制作一些快速，清晰，性能相当好的代码的重大障碍。
请注意，这些功能在3.0中已弃用，实际上已在3.1中删除（但仍通过ARB扩展提供兼容性）。在OpenGL 3.2中，他们将这些功能转移到“兼容性”配置文件中，驱动程序编写者可以选择这种配置文件。
那是什么意思？至少NVidia已经发誓要继续支持老派兼容模式以实现可预见的未来 - 他们需要支持大量遗留代码。您可以在以下幻灯片中找到对其支持的讨论：
http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more
从幻灯片＃32开始。我不知道ATI / AMD对此的立场，但我认为它会类似。
因此，虽然显示列表在技术上已从OpenGL 3.2标准的所需部分中删除，但我认为您可以安全地使用它们很长一段时间。最后，您可能希望学习OpenGL的缓冲区/着色器中心界面，特别是如果您的最终目标是信封推送游戏，但它确实不那么直观（没有glRotate，甚至！），所以我建议从良好的旧OpenGL 2.x开始。
-matt
答案 1 :(得分：5)
删除了显示列表，因为使用opengl 3+所有顶点，纹理和光照数据都存储在图形卡上，即所谓的保留模式渲染（数据保留，允许您向卡发送单个命令）绘制网格，而不是每帧都将顶点数据发送到卡片上。计算机图形学的一个主要瓶颈是RAM和gpuRAM之间的数据带宽。通过生成一次网格并保留该数据，我们可以使用齐次变换矩阵对其进行变换，并轻松绘制。这有效地减少了瓶颈，具有加载时间更长的缺点。 然而，立即模式（3.0之前）使用大量的图形带宽来每帧发送顶点数据，预先变换，重新计算法线等。 这种方法的问题有两个： 1）过多的带宽使用，以及过多的gpu空闲时间。 2）过多使用cpu时间进行计算，可以在100多个内核上并行进行，在gpu上
对此的简单解决方案是保留模式。
使用保留模式，不再需要显示列表。因此，他们从核心档案中删除。
立即模式对于学习计算机图形学理论仍然非常有用。 （这很有趣，引导）它只会在最大可能的性能方面受到影响。
维多利亚州立大学＆amp;起初，VAO可能不太直观，但就速度而言，它更为优越。互联网上有几个易于理解的opengl 3.0教程。一旦你有openGL 2.0，你应该考虑转向3.0+，因为它允许你构建非常快速的3D图形应用程序。
答案 2 :(得分：2)
虽然马修霍尔有一个很好的答案并涵盖了大部分内容，但我还是会添加一些内容。
如果你看一下被弃用的东西，你会发现它有很多客户端和固定功能。因此很明显，他们试图让人们远离以客户端为中心的代码，并让人们在GPU上尽一切可能服务器端。
当谈到使用哪种环境时，嗯，这取决于你。虽然如果表现是一个主要关注点，那么3.x可能就是要走的路。我个人肯定想学习opengl 3.x，但我怀疑我会放弃1.x / 2.x.使用1.x或2.x上下文中的可用应用程序组合快速应用程序要容易得多。
如果您想要一份已弃用的列表，请下载3.0 specification并查看“弃用模型”
答案 3 :(得分：1)
因为VBO（顶点缓冲区对象）效率更高，并且可以执行显示列表所能做的所有事情。它们实际上并不复杂，只是有点不同。除非你已经更熟悉旧式glBegin / glEnd的东西，否则你最好不要去了解缓冲区。
答案 4 :(得分：1)
未来的注意事项：最新的Direct-X，Metal和Vulkan api具有命令缓冲区和命令队列，它们允许在CPU中记录命令，然后将其发送到GPU在此处执行。因此，也许显示列表并不是一个过时的想法。实际上，编译显示列表与使用着色器和VBO正交，显示列表可以进一步提高性能。...我想知道Vulkan或Metal to OpenGL转换器是否可以将显示列表用于命令缓冲区。 / p>