glwindow on secondary monitor

hey guys...
is it possible to open a glwindow on the secondary monitor? or do i need to use the NEWTCanvasAWT embedded in a jframe?

kind regards

Hi

Using NEWT is mandatory to do this. Use the NEWT child (the last parameter of the constructor of NewtCanvasAWT), create it separately with the static create() method taking a Screen instance as a first parameter, get the second screen to use your second monitor. Best regards.

uhhhmm....something like this?

Display d = NewtFactory.createDisplay("Display");
Screen s = NewtFactory.createScreen(d, 1);
GLWindow window= new GLWindow(NewtFactory.createWindow(s, caps));

Hi

Use null with createDisplay().

sorry, it dosn't work....
it always opens the glwindow in the primary monitor.... :(

here my entirewindow creation code...

//**********************************

public class PreviewGLWindow extends GLWindow {

    PreviewRenderer renderer;

    protected PreviewGLWindow(Window window) {
        super(window);
    }

    public static PreviewGLWindow create(GLCapabilitiesImmutable caps, GraphicsDevice device, GLContext shared) {
        Rectangle w = device.getDefaultConfiguration().getBounds();

        Display d = NewtFactory.createDisplay(null);
        Screen s = NewtFactory.createScreen(d, 1);

        PreviewGLWindow preview = new PreviewGLWindow(NewtFactory.createWindow(s, caps));
        preview.setTitle("Preview");
        preview.setUndecorated(true);
//        preview.setPosition(w.x, w.x);
        preview.setSize(w.width, w.height);
        preview.setAlwaysOnTop(false);

        preview.setSharedContext(shared);
        preview.addGLEventListener(new PreviewRenderer());

        return preview;
    }
}

On Tuesday, December 20, 2011 10:48:40 AM Triipaxx [via jogamp] wrote:
>

Monitor -> Screen.

> uhhhmm....something like this?
>
> Display d = NewtFactory.createDisplay("Display");
Display d = NewtFactory.createDisplay(":0.1"); ?

It depends, ie the connection-name is native and currently only makes sense for X11
where connection-name == X11 DISPLAY name.

> Screen s = NewtFactory.createScreen(d, 1);

If the 2nd screen is not merged to the 1st one by
your desktop manager (big desktop setup) - it should work.

> GLWindow window= new GLWindow(NewtFactory.createWindow(s, caps));
>

~Sven

it still don't work.
the window is always shown on the primary monitor.
no matter if i pass in 1 or 0 or whatever as index to the createScreen()-function.
can you help me?

On Tuesday, December 20, 2011 04:42:06 PM Triipaxx [via jogamp] wrote:
>
> it still don't work.
> the window is always shown on the primary monitor.
> no matter if i pass in 1 or 0 or whatever as index to the
> createScreen()-function.
> can you help me?
>

The DISPLAY connection of Display, and Screen ID's are very OS specific.

IE. on X11:
  1 - Two or more X11 DISPLAY/Server for their Screens:
     - DISPLAY = ":0.0" or null (default), ":0.1" or ":1.0" .. depends on your setup
       This can be even a remote DISPLAY connection, ie: "192.168.0.55:0.0"

     - Screen idx: 0, 1, ..

  2 - One X11 DISPLAY/Server for 2 Screens, with Xinerama enabled (no big desktop):
     - DISPLAY = ":0.0" or null (default)
     - Screen idx: 0, 1, ..

  3 - One X11 DISPLAY/Server for 2 Screens, without Xinerama but big desktop:
     - DISPLAY = ":0.0" or null (default)
     - Screen idx: 0
     Sorry .. here you are out of luck, since all Screens are mapped as one!

Windows:
  - Forget DISPLAY, use null (default)
  - Then (1) and (2) apply as above, hence big-desktop setup will fail as well.

So which OS and Screen setup do you use ?

~Sven

I'm using windows 7 and 2 screens wich are not set up as big display.... so i should have 2 seperate screens.
but unfortunately, it's not working.
what is working, in certain sitution, is to set the position of the  the glwindow to i.e. 1920 in x and 0 in y. than the window is shown on the secondary screen. but this "workarround" only works, if the screens are aligned 0, 1 (primary left, secondary right) if you switch the position of the screens in windows (secondary left, primary right) it is allways shown on the primary monitor. i figured out, that the screen coordinates are negative for the secondary screen. so setting the position will fail what causes the glwindow to be opend on the primary screen.

i will try to embedd a NEWTCanvasAWT inside a JFrame. hopefully this will work.... :(

On Tuesday, December 20, 2011 11:58:55 PM Triipaxx [via jogamp] wrote:
Thank you for your very thorough decription.

I will try to reproduce this issue now, and hopefully be able to fix it.

Can you add a few more details about your GPU driver and the respective
multi-screen setup ? I am sorry, I haven't really digged into this on Windows yet.

The last multi screen test was a few years ago and it worked in big screen mode (duh!) :),
since I could find the option to have them in separate screens.

>
> i will try to embedd a NEWTCanvasAWT inside a JFrame. hopefully this will
> work.... :(

Don't worry we will fix this together - your help (test/input) is very welcome.

~Sven

On Wednesday, December 21, 2011 12:30:02 AM Sven Gothel wrote:
Interesting, I was digging to my code and refreshing my memories about this issue
and it looks like Windows:

- Is always using 'big desktop' mode

- I validated this w/ VirtualBox (2 Screen)

- http://stackoverflow.com/questions/1834771/how-do-you-get-createwindowex-to-create-the-window-on-a-specific-monitor

- And your experience above ..

So the 'only' bug is that NEWT doesn't allow to set
a negative x/y position at creation and setPosition(..).

Works:
- Primary 'left' works, since secondary 'right' uses positive coordinates.
- Same would work for other monitors 'below' the primary.

Buggy:
- Primary on the 'right', since secondary 'left' uses negative coordinates.
- Same bug w/ other monitors 'above' the primary.

Currently the negative position or is used as a flag of 'no custom positioning'
in general (X11, Windows, ..), which shall signal the native windowing system
to auto position the window.

To allow a negative position, hence treat the big-desktop multi monitor mode right,
we need to review the code in this regard and add a flag for 'no custom positioning',
ie. auto-positioning. I guess we can do this.

Would allowing these positions be enough, ie satisfying ?
IMHO even w/ allowing other monitors to be in the negative coordinate space,
you just don't know when you launch your application.
So if you have a use case, where you like to drop one window on each monitor,
we might need more information ?!

I will check what we actually gather from the 'EnumDisplaySettingsEx'
in our ScreenMode queries from each monitor (Screen).
Since each Window is associated with a Screen (NEWT),
we can use this information for correct positioning.

But however we solve this issue, the monitor layout is variable
and we simply cannot now which one is left or right with the current data we have.

Note: I couldn't switch the position / role of display 1 and 2 at all in VirtualBox
so the primary becomes the 'right' display.
I guess I have to attach a real 2nd monitor to a real machine to test this later on.
Or is this now the default for windows 7 ?


>
> ~Sven
>
>

nope in windows the primary monitor is always set to the first monitor attached to the graphicscard (wich is either left or right connector... i don't know), you just can set their relation, wich means.... if you switch the monitors inside of windows you need to switch them on your desk. this windows configuration only allows the mouse to get out of the the primary monitors bounds in proper direction. so if the secondary monitor is left you can leave the primary monitor on the left side...and so on....

i can remember that there was a time, windows had different ways of multimonitor representation. or .... was it the nvidia driver? whatever.... once upon a time ( :P ) there was a way to layout the monitors in horizontal/vertical span or dual view mode.... the span modes are similar to what you call a big monitor. and the dual view mode equals 2 seperate monitors. but newer versions of nvidias driver (or windows) removed this feature. i was wondering about this yesterday.... so it looks like you're right, windows always uses big monitor setup but behaves like 2 seperate monitors.

well, it may help to be able to set negative position. so in certain situation i can react on the monitor setup to put the glwindow on the right monitor.
before i decided to use newt for my preview monitor i was using the old fashion way with a jframe and a glcanvas. the jframe takes a GraphicsConfiguration object (out of GraphicsDevice) as parameter. so the jframe decided where to be opend....primary monitor or secondary. GraphicsConfiguration has a function to get the bounds out of this device (monitor).... including x/y coodinates (positive and negative) as well as width and height.
maybe you can use this information to be able to open up the glwindow on the right monitor. the getDefaultScreenDevice() from GraphicsEnvironment returns the primary monitor object.... maybe you can use this information as well....
but, it might be a lil' bit difficult to decide wich device is correct one on higher monitor counts. but maybe it is not necessary to make the decission inside of jogl.... maybe you just need a constructor of glwindow (or native window) wich takes the  GraphicsDevice object the user whishes to use.....

1st of all thank you very much for your cooperation.

On Wednesday, December 21, 2011 09:48:19 AM Triipaxx [via jogamp] wrote:
>
> nope in windows the primary monitor is always set to the first monitor
> attached to the graphicscard (wich is either left or right connector... i
> don't know), you just can set their relation, wich means.... if you switch
> the monitors inside of windows you need to switch them on your desk. this
> windows configuration only allows the mouse to get out of the the primary
> monitors bounds in proper direction. so if the secondary monitor is left you
> can leave the primary monitor on the left side...and so on....

which I couldn't do w/ Win7-Pro within VirtualBox (2 Monitors),
ie say the primary shall be the 'right' monitor.
But thats probably a VirtualBox driver problem.
yup

Yup. Guess we need both:
  - Allow negative coords to allow 'spanning' to another 'Screen'
  - If not using the 'default' Screen in Window, figure out the proper coordinates

Will do that soon ..

As it stands, we have a few bugs left in Mac OS X (AMD GPU & Some crashes),
GLJPanel (almost solved), and this one ..

~Sven
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://forum.jogamp.org/glwindow-on-secondary-monitor-tp3593579p3603496.html
> To start a new topic under jogl, email [hidden email]
> To unsubscribe from jogl, visit
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

On Wednesday, December 21, 2011 04:24:45 PM Sven Gothel wrote:
> Yup. Guess we need both:
>   - Allow negative coords to allow 'spanning' to another 'Screen'

This already works for now.


Currently I add the Screen's virtual origin as well,
allowing proper fullscreen positioning and helping w/ orientation
for user applications.

Note: The Screen's size is the virtual rotated ScreenSize.

I will check this code in later today.

>   - If not using the 'default' Screen in Window, figure out the proper coordinates

In big-desktop mode there is only one Screen, but multiple monitors
attached to it.

For proper multi-monitor support in the big-screen mode,
eg. MS Windows and X11-Xinerama (which is the default today),
we need a better ScreenMode abstraction.

This would impact the current ScreenMode API,
ie.:
 A - ScreenMode (1) - (n) MonitorMode
 B - Move ScreenMode.rotation -> MonitorMode.rotation
 C - Instead of unique ScreenMode's we would only need unique MonitorMode's
 D - Writing/Modifying would now be for the MonitorMode's .. hmm

One ScreenMode may have multiple MonitorModes (one for each attached monitor)
where the MonitorMode also contains the rotation.

I guess we have to think about this change a bit more
- or simply drop proper semantics of ScreenMode in multi monitor mode (todays behavior).

~Sven

On Friday, December 23, 2011 11:20:29 PM Sven Gothel wrote:
Another idea would be to completly wrap around the details (the single monitors)
and only handle the 'virtual' screen size.

This would make the API simple (no change) and the implementation
would need to know the monitor layout and calculate the virtual screen sizes.
Such impl. may need some time to implement but it's usage would be more easy.

~Sven

hey
i've been testing the current jogl release and it seem to work.
allowing negative coordinates does the trick for me. :)
big thanks for your work! and sorry for answering late!