調試GLX應用程序 - 呆滯窗口不重繪

我移植的OpenGL應用程序到Linux（Debian的傑西核心，通過梅薩10.3.2使用GLX，X11和XFree86，GL 3.0）。我被困在一個渲染問題上，我不完全理解（下面的描述），並且我已經用盡了我知道如何使用的調試方法。我的問題是，我如何處理調試呢？有沒有我可以用來檢查性能的工具，我可以查看的日誌文件，我可以安裝和設置斷點的開發庫，還有其他的東西？調試GLX應用程序 - 呆滯窗口不重繪

症狀：

一旦窗口被實例化，窗框繪製，但窗口的內容中沒有畫出（我看到在窗口的桌面背景）
標題欄上單擊並拖動移動窗口緩慢
關閉應用程序需要幾秒鐘，但在窗口被破壞之前的一瞬間，正確的屏幕輸出出現在窗口中
調整窗口的大小非常小改善污泥ggishness或顯示問題
top揭示了只有2％的CPU的最大使用量（大部分範圍0.3之間的時間 - ％0.7），內存使用上升和下降，但保持在一個穩定的範圍內，並且我的圖形應用程序的其餘部分有點滯後，但系統的其他部分相當活潑。下面是從top快照：

 
top - 01:09:42 up 3:43, 3 users, load average: 0.31, 0.12, 0.12 
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie 
%Cpu(s): 0.3 us, 0.4 sy, 0.0 ni, 99.2 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st 
KiB Mem: 16411604 total, 1342704 used, 15068900 free, 47860 buffers 
KiB Swap: 2783228 total,  0 used, 2783228 free. 752736 cached Mem 
PID USER  PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND                  
3758 andrew 20 0 145700 25080 16704 R 0.3 0.2 0:02.36 mtexec

我已經試過：

我已經在Windows上運行類似的問題，問題出在哪裏路過一個空窗口句柄SwapBuffers通話。我在我的glXSwapBuffers調用中運行了gdb並確定了斷點，並確保現在不會發生同樣的情況。
通過使用gdb確保該Display*和Window情況下不爲空，而不是被改變的窗口創建代碼跟蹤。
重繪和Expose和ConfigureNotify事件未重繪。刪除重繪代碼似乎對問題沒有任何影響。
萬一它很重要，我使用GLEW，但不適用於上下文創建。我得到一個函數指針glXCreateContextAttribsARB通過glXGetProcAddress。

來源

2016-07-23 Andrew C.

應用程序的內存使用量在運行時是否增長？ – SurvivalMachine

我現在正在觀看它，記憶以非常低的增量上升和下降，而且似乎不會長時間增長。 –

我在這個問題上取得了一些進展。我刪除了我用來枚舉視頻模式的XFree86代碼，現在我得到了屏幕輸出。我也相信另一個問題是潛伏在我的舊代碼中，一個X11'Window'對象的淺拷貝導致了一些問題。作爲參考，這個例子正在爲我工作：https://www.opengl.org/discussion_boards/showthread。php/165856-Minimal-GLX-OpenGL3-0-example –

關於如何調試此問題的問題的簡短答案：檢查您的顯示器枚舉是否提供了一個實際上與您的X11顯示器兼容的GLXFramebufferConfig。如果混合glX與Xf86庫調用，儘量只使用glX讓程序運行起來。詳細解釋細節的一個很好的資源是Programming OpenGL in Linux: GLX and Xlib指南。

來源

2016-07-23 23:02:26

調試GLX應用程序 - 呆滯窗口不重繪

回答

相關問題