A bad interaction between Mesa 10 and Gnome, but only at full screen

I’m not sure where to begin, I have a ‘kiosk’ application that works just fine with Nvidia hardware GT610 and the 319 Nvidia driver. My OpenGL code draws with glDrawBuffer(GL_FRONT_AND_BACK) but also eventually, calls glXSwapBuffers(). When the code launches full screen mode (no decorations of any kind) it does so with an EWMH event and things work great. I’m using Linux Mint with the Mate/Gnome Window Manager.

I’m trying to get the same code working with Mesa 10 and Intel HD4400 Haswell Mobile graphics. The code works fine except when the system goes full screen. At that point the drawing to both front and back buffers seems to stop but the swapping continues and the display flashes front/back at 30Hz. If I fill the screen with a normally decorated window, things are just fine – no flashing, front and back buffers get written to, all is good.

I have tried to set the OpenGL mode to single buffer mode, I have turned off the calls to glXSwapBuffers() but then there is no drawing output at all.

It seems that there is a bad interaction between Mesa 10 and the Window Manager but only when the Window Manager goes full screen. As if glDrawBuffer(GL_FRONT_AND_BACK) has stopped working. Further experiments suggest that Mesa 10 NEVER draws to the front buffer but ONLY the back buffer.

Out of desperation I have attempted to bypass the Window Manager completely and adjust the window with override_redirect calls. It kinda works, but I can see some evidence that the Window Manager is fighting back. I doesn’t matter that I confuse things with the Window Manager since this is a kiosk application.

Any suggestions please? Should I post this to the Mesa folks?

----- later

The great thing about writing to a forum is that it requires one to write clearly (or as clearly as possible) about a problem. The process of explaining the problem often suggests a solution. In my case I have ‘solved’ the problem by starting OpenGL in single buffer mode but retain the calls to glXSwapBuffers() which, of course makes no sense! It then seems that Mesa 10 behaves itself. I think there is something broken in Mesa 10 with respect to drawing to buffers GL_FRONT, GL_BACK, GL_FRONT_AND_BACK – I suspect it only does GL_BACK.

So I have a work-around…

You lost me. Right there. Why are you drawing to both the FRONT and BACK ? You might as well just allocate a single-buffer and put a flush at the end instead. With a double-buffered frame buffer you typically draw to the BACK while displaying the FRONT. That way your rendering doesn’t hose-up what the user is look at, and if you have sync-to-vblank enabled, you avoid tearing effects when the swap is done. But if you don’t care about artifacts, just allocate a single-buffer and flush at the end.

Further experiments suggest that Mesa 10 NEVER draws to the front buffer but ONLY the back buffer.

Hmmm. Can’t speak to that. But let me ask you something that’s possibly related. Are you running a compositing window manager, and if so do you have compositing enabled? If so, try disabling it. Drawing pixels to the front buffer can fail when there is an occluding window (that is, when the pixel ownership fails). I don’t know how this is handled with compositing window manager, but I wouldn’t be surprised if all FRONT buffer pixels might fail the pixel ownership test in this case (because none of them are visible on the screen – all the compositing happens off-screen).

Out of desperation I have attempted to bypass the Window Manager completely and adjust the window with override_redirect calls. It kinda works, but I can see some evidence that the Window Manager is fighting back. I doesn’t matter that I confuse things with the Window Manager since this is a kiosk application.

I’m not sure, but it sounds like you may be fighting two different problems. First, for full screen windows, you don’t need a window manager. But if you decide to run one, you certainly don’t need much of one. Any simple one will do. And if you decide to use a full-up modern window manager such as KDE or Gnome, definitely be sure to disable that perf wasting compositor!

As far as disabling window decorations, this should work (works for me):

FWIW, the 5 is PROP_MOTIF_WM_HINTS_ELEMENTS from <Xm/MwmUtil.h>, if you have that installed. You may not. And with the “5”, you don’t need it.

…I have ‘solved’ the problem by starting OpenGL in single buffer mode but retain the calls to glXSwapBuffers() which, of course makes no sense! It then seems that Mesa 10 behaves itself. I think there is something broken in Mesa 10 with respect to drawing to buffers GL_FRONT, GL_BACK, GL_FRONT_AND_BACK – I suspect it only does GL_BACK.

I don’t know if this is Mesa or this is an artifact of your window manager config. But drawing to the FRONT buffer in a double-buffer config is really odd. Would definitely like more information about why you are doing this at all.

What I think was happening is that the WM (Gnome / Mate) behaves correctly when OpenGL commands it to draw to both front and back buffers. In full screen mode, I think the WM is bypassed and Mesa talks directly to glx. It seems that Mesa 10.1 with the Haswell HD4400 graphics then only writes to the back buffer even if it is told to write to the front or both. The behaviour is correct when the WM is involved. The behaviour is correct with Nvidia too.

My application is not very performance oriented so it hasn’t mattered that I set up a double-buffered system and swap buffers as usual, but under some circumstances choose to draw to both front and back buffers. I’m using the front buffer to accumulate an image. When the back overwrites the front it’s, of course, a time wasting null operation. My application periodically reads the front buffer and susbsequently chooses what to draw based on what has already accumulated. It’s strictly 2D stuff.

I have things working smoothly now: I detect a Haswell processor and set up OpenGL in single buffered mode (if not Haswell then double buffered) – with this, both the Nvidia platform and the Haswell platform behave identically.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.