X11 GLX development

[niewiadomokto]

XCloseDisplay(display);

this line crashes whole x11 while running/developing opengl apps using compton and floxbox, no problems on xcompmgr, and running fullscreen opengl app with no transparency makes compton use 100 cpu power.

[richardgv]

As an OpenGL developer you should know what is the correct way to report an issue. With this limited information -- no program code, no driver info, no backtrace -- it's impossible to figure out what's wrong.

compton has been here for a few years, and I don't remember any reports that it would crash a proper-written OpenGL application on a sane driver.

Please make sure you are using GLX backend instead of X Render, unless you found GLX backend is causing the crash. X Render frequently uses software rendering and is too slow to handle such cases. Some of those GLX backend optimization options could be pretty useful, as well.

If neither your application or compton is limiting the painting rate, most likely they will either exhaust GPU or CPU . Use your driver's VSync option, --sw-opti, or --vsync may help. This may also has something to do with application or driver, as on my work computer, with VSync disabled, neither compton (GLX/XRender) or the full-screen glxgears is using a substantial part of CPU (1680x1050, GTX 650, nvidia-drivers-325.15, FPS roughly 1600).

[niewiadomokto]

glxgears hangs just like my apps, using lastest fglrx from ati website, i cant post any traceback because there is no error, screen simply freezes when i close any opengl app and windows decorations dissapear, then cpu usage goes up ( i think so because of fan speed increase :) ) and then i need to stop xserv by ctrl-alt-backspace so i can start it up again. i stole compton-config from some website and even didnt read it because i am lazy m-f who just want to move his fluxbox windows tearfree and your code does it better than xcompmgr , but after checking it out i can say that i am using glx :), will try it on some other driver and post my progress

[richardgv]

glxgears hangs just like my apps, using lastest fglrx from ati website.

Perhaps a driver issue, then. fglrx has almost the most broken X composite support among all the drivers, and it has various issues in OpenGL as well. I haven't received such severe reports, though.

You could try to adjust your compton configuration (or use --config /dev/null), X configuration, and driver configuration. I heard there's a fglrx option called "OpenGLOverlay" that has some effect on OpenGL compositors.

i cant post any traceback because there is no error, screen simply freezes when i close any opengl app and windows decorations dissapear, then cpu usage goes up ( i think so because of fan speed increase :) )

Use gdb to attach to X or compton, but make sure you built them with debugging symbols or have debugging symbols installed. For more complex scenarios, a global profiler (sysprof, perf, etc.) or application wide profiler (callgrind, etc.) could be helpful.

and then i need to stop xserv by ctrl-alt-backspace so i can start it up again.

Doesn't killing compton from a virtual console work?

i stole compton-config from some website and even didnt read it because i am lazy

Which unfortunately feels like a bad habit...

[CossRooper]

This reminds me of #114, I had very similar problems. I honestly think it is an FLGRX issue.

In my case, I eventually gave up on FGLRX and went back to the Oibaf's git builds of Mesa, which work flawlessly.

[richardgv]

Quote from an interesting article Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame:

The quality of the code in the userland AMD driver looks horrible from the outside: using valgrind on a program using the AMD driver causes valgrind to complain about the large number of errors (ioctls using unintialized structures, access to unintialized memory). In some error cases, instead of reporting an error to the caller, the AMD driver will simply call exit(123) and kill the whole application. This kind of issues impacted SDL 1.3: calling XCloseDisplay caused the driver to exit. A workaround was put in place later in SDL 2.0 to avoid this problem which should have never happened in the first place. Fun fact: this bug was found while writing a minimal program that reproduce the mipmapping issue…

So, SDL dies on XCloseDisplay() because of the shit in your drivers as well. Investigate into SDL's workaround, if you are interested.

[niewiadomokto]

Didnt have time to switch to mesa yet, but chromium crashes with any webgl content with compton, so its not only XCloseDisplay() problem.

[richardgv]

With GTX 670 and nvidia-drivers-325.15, Saint Jean Cathedral works correctly under chromium-30.0.1599.47 or firefox-24.0-r1, with compton on GLX backend. Presumably this is your driver again. What is crashing this time, X, Chromium, or compton?