2

I've written an OpenGL application in Linux through GLX. It uses double buffering with glXSwapBuffers and Sync to VBlank set via NVIDIA X Server Settings. I'm using Compiz and have smooth moving of windows and no tearing (Sync to VBlank enabled in Compiz settings). But when I

  1. Try to move or resize the OpenGL window or

  2. Move other windows through the area occupied by the OpenGL window

the system stutters and freezes for 3-4 seconds. Moving other windows outside the area occupied by the OpenGL window is smooth as always. Moreover the problem only arises if the OpenGL application is in the loop of producing frames of animation therefore swapping the buffers. If the content is static and the application is not swapping the buffers there are no problems,moving the various windows is smooth. Could be a synchronization issue between my application and Compiz?

Bill the Lizard
  • 369,957
  • 201
  • 546
  • 842
disquisitiones
  • 87
  • 2
  • 8

1 Answers1

2

I don't know if it's still in the same shape as a few years ago, but…

Your description matches very well a Compiz SNAFU. Every window resize triggers the recreation of a texture that will receive the window contents. Texture creation is a costly operation and hence should be avoided. Unfortunately the Compiz developers don't seems the brightest ones, because they did not realize there's an obvious solution to this problem: Windows in X11 can be reparented without much cost (every Window manager does this several times), it's called stacking. Compiz is a window manager.

So why doesn't Compiz keep a desktop sized window around into which it reparents those windows that are about to be resized, gets its constant sized window texture from there and after finishing the resize operation reparents the window into its decoration frame?

I don't know why this is the case. Anyway, some things Compiz does are not very smart.

If you want to fix this, well: Compiz is open source and I just described what to do.

datenwolf
  • 149,702
  • 12
  • 167
  • 273
  • @disquisitiones: Yes IMHO the KWin developers are as clueless about OpenGL as the Compiz devs. And quite frankly, several things Qt does with OpenGL are not optimal either :( – datenwolf Jan 04 '13 at 00:04
  • Thanks datenwolf, yes it seems a problem related with the window manager. After your answer I've tried some alternatives: with evilwm and xfwm in fact the problem disappears (but with tearing of moving windows, as those window managers do not use double buffering) . I admit that I use Compiz for the sole reason of eliminating tearing in moving windows (frankly a thing that I find unacceptable). So it seems impossible to get a window manager for X11 wich both uses double buffering and is carefully written so as to avoid the problem in object. Then the only way seems to dive into source code. – disquisitiones Jan 04 '13 at 00:30
  • @disquisitiones: Normally if V-Sync is enabled in the driver settings, tearing should not happen if a window is moved, regardless of using a compositor or not. – datenwolf Jan 04 '13 at 00:33
  • ehm... Excuse me for the double comment. An enter key was inadvertently pressed... The second comment was supposed to be the intended. Thanks again! – disquisitiones Jan 04 '13 at 00:35
  • No, I can confirm this by experience. I always have V-Sync enabled in the drivers but in xfwm and evilwm the tearing is huge. I suppose that the application has to use double buffering in the code to get a correct the result, in addition to V-Sync right? (again that enter key, damn :-)) – disquisitiones Jan 04 '13 at 00:37
  • @disquisitiones: Interesting. I'll try to reproduce this. What specs does your system have? GPU, driver version, X.org version. – datenwolf Jan 04 '13 at 00:38
  • GPU: NVIDIA GeForce 210 NVIDIA Driver Version 302.17 X.Org X Server 1.7.6 X Protocol Version 11, Revision 0 – disquisitiones Jan 04 '13 at 00:48