我正在渲染由大约500k个三角形组成的相当重的对象。我使用opengl显示列表，在渲染方法中只调用glCallList。我认为一旦图形图元被编译到显示列表中，cpu的工作就完成了，它只是告诉gpu绘制。但现在一个cpu核心的负载达到100%。
你能给我一些线索吗？为什么会发生这种事？
更新：我已经检查了运行glCallList需要多长时间，它很快，运行它大约需要30毫秒
很可能您达到了列表长度的限制，即每个列表有64k个顶点。试着把你的50万个三角形（15万个顶点？）分成更小的块，看看你得到了什么。
顺便问一下，你在用什么图形芯片？如果顶点在CPU上处理，这也可能是一个问题
显示列表神奇地将所有内容卸载到GPU，这有点像神话。如果真的是这样的话，纹理对象和顶点缓冲区就不需要添加到OpenGL中。所有的显示列表实际上都是一种方便的方式来回放OpenGL调用序列，并有望节省一些函数调用/数据转换开销（请参阅此处）。据我所知，我使用的PC硬件实现似乎都没有做过更多的事情；也许在SGI工作站的时代是不同的，但现在缓冲区对象是可行的。（现代OpenGL书籍，如OpenGL Distilled，在进入新内容之前，只对glBegin/glEnd等进行了最简短的提及）。
我看到的显示列表产生巨大影响的一个地方是GLX/X11案例，其中您的应用程序远程运行到您的显示器（X11"服务器"）；在这种情况下，使用显示列表确实只将所有显示列表状态推送到显示侧一次，而非显示列表即时模式应用程序需要在每帧使用更多带宽再次发送一堆内容。
然而，抛开显示列表不谈，您应该意识到vsync和忙于等待（或其幻觉）的一些问题。。。请参阅此问题/答案。