Многие проблемы рисования OpenGL поменяли местами буферы - PullRequest
1 голос
/ 20 августа 2011

У меня проблема с замедлением при использовании openGL с gtk (хотя gtkglext) и при анимации.

По сути, у меня есть приложение, которое выполняет определенные отображения с использованием OpenGL в приложении GTK. Многие окна могут быть открыты одновременно (и некоторые окна могут иметь несколько областей рисования). Таким образом, можно иметь на экране сразу 20-30 областей рисования openGL. Ни один из рисунков не является слишком тяжелым, и openGL делает это очень быстро.

Моя проблема возникает, когда все эти дисплеи анимируют, что действительно замедляет работу приложения. После долгих исследований этой проблемы я решил, что вызов буфера подкачки для openGL вызывает мои проблемы. При рисовании в GTK вы должны делать все свои рисунки в событии выставления виджетов. Поэтому, когда вы хотите нарисовать, вы вызываете gtk_widget_queue_draw для виджета области рисования, а затем, когда GTK обрабатывает свои события, он будет вызывать событие expose последовательно для всех виджетов, которые нуждаются в рисовании. Проблема возникает, когда после рисования мне нужно вызвать своп-буферы, чтобы нарисовать фактический openGL на экране (из-за двойной буферизации). Этот вызов блокируется (потому что vysnc включен), пока монитор не обновится. Это не проблема, когда на экране есть, скажем, 3 области рисования, но при наличии одной тонны возникает куча вызовов буфера подкачки, которые блокируют и действительно замедляют работу приложения, поскольку каждый из этих вызовов буфера подкачки вызывается в их собственное выставленное событие, и ни одно из них не синхронизировано.

Тогда у меня вопрос, есть ли способ синхронизировать все вызовы буфера подкачки, чтобы не было так много блокировок. Отключение vsync (само по себе отвратительно, потому что это зависит от конкретной реализации OS / openGL) устраняет проблему со скоростью, но возникают проблемы. Я не уверен, как многопоточность поможет, потому что я должен сделать обменные объекты в событии GTK-экспозиции, чтобы рисунок синхронизировался с GTK, если нет чего-то, о чем я не думаю.

Любая помощь будет оценена!

Ответы [ 2 ]

0 голосов
/ 21 августа 2011

Типичный подход к решению этой проблемы - использование собственного потока для каждого контекста OpenGL для замены.

Однако разработчики OpenGL могут (и я должен сказать) представить новое расширение, которое вводит «согласованные перестановки» или что-то в этом роде. Есть несколько расширений синхронизации, в частности http://www.opengl.org/registry/specs/OML/glx_sync_control.txt

0 голосов
/ 21 августа 2011

Если у вас более 20 окон, что вы ожидаете?Каждый из них синхронизирован с одним и тем же временем: обновление экрана.Каждому из них придется выполнить кучу операций с памятью в течение этого времени.Все одновременно.Конечно, будет замедление.Если у вас нет более 20 процессоров, им придется стоять в очереди один за другим.

На самом деле, вы не можете ничего сделать, кроме как ограничить количество окон GL, отображаемых пользователю.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...