0

I am porting an OpenGL application to Linux (Debian Jesse core, using GLX, X11 and Xfree86, GL 3.0 via Mesa 10.3.2). I'm stuck on a rendering problem that I don't fully understand (description follows), and I have exhausted the methods of debugging that I know how to use. My question is, how do I approach debugging this? Is there a tool I can use to inspect performance, a log file I can look at, a development library I can install and set breakpoints on, something else?

The symptoms:

  • Once the window is instantiated, the window frame is drawn but the window contents are not drawn (I see the desktop background in the window)
  • click-drag on title bar to move the window around is sluggish
  • Closing the app takes several seconds, but for a very brief instant immediately before the window is destroyed, the correct screen output appears in the window
  • Resizing the window to be very small does not improve the sluggishness or display problem
  • top reveals a max usage of only 2% cpu (most of the time it ranges between 0.3 - 0.7%), memory use rises and falls but stays in a steady range, and the rest of my graphical apps suffer a little lag but the rest of the system is fairly snappy. Here's a snapshot from 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

What I've tried:

  • I have run into a similar problem on windows, where the problem was passing a null window handle to a SwapBuffers call. I ran gdb with a breakpoint on my glXSwapBuffers call and made sure the same thing is not happening now.
  • Tracing through the window creation code using gdb making sure that the Display* and Window instances are not null and not being changed.
  • Redrawing and not-redrawing on Expose and ConfigureNotify events. Removing the redraw code does not seem to have any effect on the problem.
  • In case it matters, I am using GLEW, but not for context creation. I get a function pointer to glXCreateContextAttribsARB via glXGetProcAddress.
  • Does the application's memory usage grow while it's running? – SurvivalMachine Jul 23 '16 at 04:57
  • I'm watching it right now, memory is rising and falling in very low increments, and does not appear to be growing over long period of time. –  Jul 23 '16 at 05:03
  • I made some progress on this problem. I removed the XFree86 code I was using to enumerate the video modes, and now I get screen output. I also believe that another problem was lurking in my old code, that a shallow copy of an X11 `Window` object caused some of the problem. For reference, this example is working for me: https://www.opengl.org/discussion_boards/showthread.php/165856-Minimal-GLX-OpenGL3-0-example –  Jul 23 '16 at 19:12
  • I'm going to leave this question up while I narrow down the code problem and paste the offending code back to the original question. –  Jul 23 '16 at 19:25

1 Answers1

1

The short answer to my question about how to debug this problem: check that your display enumeration is providing a GLXFramebufferConfig that is actually compatible with your X11 display. If you are mixing glX with Xf86 library calls, try just using the glX to get the program up and running. A good resource that explains the details is the Programming OpenGL in Linux: GLX and Xlib guide.