许多OpenGL绘图区域交换缓冲区减速问题

时间:2011-08-20 14:41:32

标签: opengl gtk

当使用带有gtk(尽管是gtkglext)的openGL并进行动画制作时,我遇到了一个减速问题。

基本上我有一个应用程序在GTK应用程序中使用OpenGL进行某些显示。许多窗口可以一次打开(某些窗口可以有多个绘图区域)。因此可以在屏幕上同时说出20-30个openGL绘图区域。没有任何绘图太重,openGL非常快。

我的问题出现在所有这些显示都是动画的时候,它真的会减慢应用程序的速度。经过对该问题的大量研究后,我确定它是对openGL的交换缓冲区调用导致我的问题。在GTK中绘图时,您可以在窗口小部件公开事件中完成所有绘图。因此,当您想绘制时,在绘图区域窗口小部件上调用gtk_widget_queue_draw,然后当GTK处理其事件时,它将在需要绘制的所有窗口小部件上串行调用expose事件。问题出现在绘图完成后,我需要调用交换缓冲区来绘制屏幕上的实际openGL(因为双缓冲)。此调用似乎阻止(因为vysnc已打开),直到监视器刷新。当屏幕上有3个绘图区域时,这不是问题,但是当有吨时,有大量的交换缓冲区调用全部阻塞并且实际上减慢了应用程序因为每个调用这些交换缓冲区调用他们自己的公开事件,没有一个是同步的。

我的问题是,是否有某种方法可以同步所有交换缓冲区调用,因此没有那么多阻塞。关闭vsync(丑陋本身因为它的OS / openGL实现特定)修复了速度问题,但随后出现了撕裂问题。我不确定多线程将如何帮助,因为我必须在GTK公开事件中执行swap缓冲,因此绘图与GTK同步,除非有一些我没想到的东西。

任何帮助将不胜感激!

2 个答案:

答案 0 :(得分:0)

如果您有20多个窗口,您期望什么?每一个都是同一时间:屏幕刷新。在此期间,每个人都必须做一堆内存操作。一切都在同一时间。当然会有减速。除非你有20多个处理器,否则它们必须排在第二位。

实际上,除了限制向用户显示的GL窗口数量之外,您无能为力。

答案 1 :(得分:0)

解决此问题的典型方法是使用自己的线程为每个OpenGL上下文进行交换。

然而,OpenGL实现者可以(我们应该说)引入一个新的扩展,引入“协调交换”或类似的东西。有一些同步扩展,最值得注意的是http://www.opengl.org/registry/specs/OML/glx_sync_control.txt