PBuffer On Second X Screen Fails

JOGL version RC10
Fedora 12
Sun/Oracle JDK 7u7

We have some PBuffer code that was working until we tried to move it to a second X screen (not TwinView, but a second screen as in DISPLAY=":0.1").  After we did that an attempt to make the PBuffer's context current threw a GLException.

We did some poking around and found that during the createGLPbuffer call we ended up at a spot in X11GLXDrawableFactory that assumed screen 0.  In RC10 there are two such places in X11GLXDrawableFactory, on lines 240 and 517.  They look like this respectively:

240:                final X11GraphicsScreen sharedScreen = new X11GraphicsScreen(sharedDevice, 0);

517:    final X11GraphicsScreen screen = new X11GraphicsScreen(device, 0);

Not that this is right or wrong, but when we changed these to get the screen number from some nearby connection then the problem disappeared and the PBuffer stuff started working again:

240:                 final X11GraphicsScreen sharedScreen = new X11GraphicsScreen(sharedDevice, X11GLXDrawableFactory.getScreenNumberFrom(connection) );

517:     final X11GraphicsScreen screen = new X11GraphicsScreen(device, getScreenNumberFrom( device.getConnection() ) );

...where getScreenNumberFrom(String connection) is some new method we added to pull the screen number from a connection string (there probably is a simpler way to do this than what we did).


Is this a bug, or is the assumption of screen 0 intentional and it's pointing to some other problem in our PBuffer usage?  This PBuffer code used to work in JOGL 1.1.1a, but a lot has changed since then so we may have some lingering porting flaws.

On 09/12/2012 12:18 AM, rhatcher [via jogamp] wrote: I assume you use that pbuffer context w/ an onscreen context on that
device/connection/screen.

It is a bug in current RC10.
Haven't tested non Xinerama/TwinView configs for a long time, my bad.

Thank you for catching it and providing a fix.

If you like, pls file a bug report and add this patch of yours,
or a pull request. I will add this fix to the upcoming FBO as well.

~Sven

On 09/12/2012 04:39 AM, Sven Gothel wrote:
I assume we want the offscreen/pbuffer drawable
on the named device in the actual function call.

Like to see your complete patch to discuss, hence bug report might
be best to have it documented well.

~Sven

Sven,

The bug was filed at https://jogamp.org/bugzilla/show_bug.cgi?id=615 along with the modified version of X11GLXDrawableFactory.

As I mentioned in the bug report, our expertise in this area is limited so this "fix" might be completely inappropriate and really should be evaluated by somebody who knows more about what's going on in this area.  However, it did fix the problem, and on initial thought at least it seems reasonable that an assumption of screen 0 might eventually cause problems.

I haven't had much time yet to run through our system with this change in place, but FWIW I haven't seen any other problems so far on either of two screens after the change.  My current intention is to replace our current RC10 jars with this "RC10++" version and let the entire team run with it for a while to get a broader usage history.


Regarding intention of the code, this particular PBuffer code is a render-to-texture emulation.  We accumulate stuff in the PBuffer, then transfer it onto some geometry later.

The PBuffer shares a context with the other on-screen graphics.  The line that creates the PBuffer looks like this in the version that's working after the X11GLXDrawableFactory tweek:

                _pbuffer = GLDrawableFactory.getFactory( GLProfile.get( GLProfile.GL2 ) ).createGLPbuffer(
                    drawable.getNativeSurface().getGraphicsConfiguration().getScreen().getDevice(),
                    caps, null, _drlmsTexWidth, _drlmsTexHeight, drawable.getContext()
                ) ;

It used to look like this:

                _pbuffer = GLDrawableFactory.getFactory( GLProfile.get( GLProfile.GL2 ) ).createGLPbuffer(
                    null, caps, null, _drlmsTexWidth, _drlmsTexHeight, drawable.getContext()
                ) ;

...but we changed the first argument during the course of investigating this problem and I haven't changed it back to see if null also would work as the first arg.  FYI the first arg was changed because our initial assumption was that the null was causing some inappropriate default to be used.  However, this change alone didn't fix the issue, and that's when we started digging deeper.