GLWindow

I've got a multi-monitor setup, and my goal is place a single GLWindow on each monitor in full-screen mode. I've gone through most of the test cases, which demonstrate how to bring up a GLWindow on the main monitor:

  GLCapabilities caps = new GLCapabilities(GLProfile.getDefault());
  Display display = NewtFactory.createDisplay(null);
  Screen screen = NewtFactory.createScreen(display, 0);
  GLWindow window = GLWindow.create(screen, caps);

  window.setFullScreen(true);
  window.setVisible(true);

Now, I've tried every combination under the sun to get a GLWindow to come up on some other monitor besides the main one, without success. What is the magic I am missing?

As a reference, the code below represents the SWING/AWT equivalent of what I am trying to do with NEWT:

  GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();

  for (GraphicsDevice dev : env.getScreenDevices())
  {
      JFrame frame = new JFrame();

      // add components to the frame, formatting, etc.

      dev.setFullScreenWindow(frame);
  }

Part of this is so I can provide Brandon with a proper testcase for this GLG2D issue.

Here is my environment:

1) Window 7 Professional x64
2) jdk1.7.0_06
3) eclipse 4.2.1.v201209141800

4) jogl.README.txt:
This is build version 2.0-b66-20121101, based on:
branch  rc
commit  502847f59ef01c78a85e4ee5453a09d9b83d9a5e

Thanks for the help : )

Hi

Please use the latest autobuild (even though it might not be enough to solve your problem). Don't try to use exclusive full screen mode as a first step, modify the second parameter passed to createScreen().

I'm having the same issues with the autobuild. Maybe I'm approaching this from the wrong angle.

Take a look at this test case, which demonstrates the fundamental limitation I'm running into. WARNING : this test causes significant flickering in the screen, and my hurt your eyes. All the test does is repeatedly clear the viewing surface with a black and white background, which should be a trivial operation.

It is not entirely clear what else is gained when entering Fullscreen, but at the very least we are able to sync with the monitor's refresh rate. Unless there is a way to vsync in windowed view, you will see skipping in the animation regardless of GL work being done and the FPS you can achieve.

I've noticed that the more powerful your graphics card is, the less obvious this problem is. We tested with a GTX 690 using its parallel performance mode, and still had the skipping problem which we identified using an oscilloscope. And it is not just JOGL ... AWT/SWING, LWJGL, and even D3D had the same problem.

Now, it is my understanding that JOGL uses WGL and GDI as the native Windows implementation. After reading this article on MSDN, it sounds like what I'm trying to do is simply not possible.

The newer graphics architecture, DXGI, does support multiple fullscreen swap chains. However, I doubt any of us have the time to implement JOGL on DXGI. It might be worth putting on the roadmap though, and I would be interested in working on this in the future.

I don't think it would be easy to port to D3D, since none of us have worked with the architecture and I doubt there are bindings for it in Java that are as intuitive as JOGL. Not to mention that kills our portability in the future.

As an interim solution, I have the ability to span exactly 3 monitors with the GTX 690 (I haven't tested it yet though), which means I could probably get away with a single canvas. It's not an ideal situation, but it should work.

If you guys have any other suggestions or routes I could explore, please feel free to post them here.

You haven't tried my second suggestion?

I stopped trying to use full screen mode when I realized I couldn't get a window to come up on a different monitor. Did you mean doing something like this?

Display display = NewtFactory.createDisplay(null);
Screen screen = NewtFactory.createScreen(display, 0);
Screen screen = NewtFactory.createScreen(display, 1);

The window always comes up somewhere on my default device, regardless of what I pass to createScreen(). It makes sense though, because each screen is using NewtFactory.createDisplay(null), which returns the default graphics device (which I assume is my primary monitor as Windows sees it).

If you meant NewtFactory.createDisplay( some_name ), well then I am at a loss. I followed the documentation which took me to AbstractGraphicsDevice.getConnection(), and then I wasn't sure what to do next. Is there a way to enumerate available devices or connection names for the particular platform?

If not through JOGL, how would I go about doing this? I'll try looking through the GDI documentation while I wait. Maybe I'll get lucky

Have you tried to use Display.getAllDisplays()?

Yes, the collection is emtpy until I make calls to Display.createDisplay(..).

On 02/04/2013 07:00 PM, Daniel Avila [via jogamp] wrote:
> I'm having the same issues with the autobuild. Maybe I'm approaching this from
> the wrong angle.
>
> Take a look at this test case <https://gist.github.com/4707452>, which
> demonstrates the fundamental limitation I'm running into. /*WARNING*/ : this
> test causes significant flickering in the screen, and my hurt your eyes. All
> the test does is repeatedly clear the viewing surface with a black and white
> background, which should be a trivial operation.
I see .. :)

>
> It is not entirely clear what else is gained when entering Fullscreen, but at
> the very least we are able to sync with the monitor's refresh rate. Unless
> there is a way to vsync in windowed view, you will see skipping in the
> animation regardless of GL work being done and the FPS you can achieve.

I see you have enabled VSYNC, good:
        gl.setSwapInterval(1);
You seem to experience 'tearing' due to incorrect VSYNC.

We use the platform agnostic OpenGL API
and platform dependent windowing bindings APIs EGL, GLX, WGL, CGL, ..

'gl.setSwapInterval(1);' invokes the EGL, GLX, WGL, CGL .. equivalent call.

It is up to the driver implementer to make this function work properly
regardless of windowing- or fullscreen-mode.
Of course, in fullscreen mode it is easy to get the VSYNC right,
since no other renderer activity is being performed.

In windowing mode users see different artifacts every now and then.
For example on X11/ATI-proprietary the actual swap-interval value is
multiplied be the many windows requesting one, e.g.:
  4 windows -> vsync on every 4 frames

On X11/NVidia I haven't experienced tearing, but I also haven't
checked too closely.

In your case VSYNC seems to be ignored.

The VSYNC behavior also depends heavily on the window manager (WM) mode,
i.e. compositing or 'direct' - so respecting OS, driver and WM
we get quite a huge dimensional space for error here.

There is on OpenGL related extension: WGL_NV_swap_group
which is abstracted in GLContext. However this extension is
related to NVidia only and only supported in the professional cards/drivers.

See unit test: com.jogamp.opengl.test.junit.jogl.acore.TestNVSwapGroupNEWT

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestNVSwapGroupNEWT.java;h=54f99433cc8bbaa77d0675bf3d3ed47c7f4e753e;hb=HEAD#l75

Since this is not a native JOGL issue and if this is really important to you,
my recommendation is to check combinations of drivers (incl. OS) and WM modes.
You may like to test w/ compositing turned off .. etc.
If there is a reliable way for your WM .. we may be able to add a quirk/workaround.

Maybe you like to document a WM/WM-Mode/OS/driver matrix regarding VSYNC.

~Sven