Hi all,
I’ve been out of the 3D scene for the last year while concentrating on becoming certified with www.nremt.org, so please forgive me if this has been covered. I’ve obviously missed it.
When I did my original NeHe demos, the method GLEventListener.displayChanged() was unimplemented. Is this still true?
Hi,
interesting question but as far as I know it’s still unimplemented. I will try to find out more and if there’s something new to know I will inform you…
From what we can tell, no, it hasn’t been implemented. We’re not seeing any of the callbacks being made. We have some dual screen/video card setups here and we would expect to see a displayChanged() callback when we drag the window from one screen to the other, but currently we are not.
No, it isn’t currently implemented. The JAWT doesn’t appear to provide enough information to allow JOGL to detect when a GLCanvas has moved from one screen to another. Does the AWT itself handle this properly? I don’t have a multihead machine to experiment with, but I thought there were issues around creating a Frame on one screen and dragging it to another.
Thought I’d give you a little hope… 
To date, I’ve had no issues with using a multi-headed display.
I’ve also had no troubles with a 3DLabs VP880Pro once I enabled GL on the second screen via the drivers.
I can drag active canvases between screens, even going as far as leaving half of the canvas on one screen and half on the other. All continues to work fine.
I’ve also had no troubles with the VP880 under Linux and XiG’s Summit X server, and that’s even running 2048x2048 on the primary display.
I don’t to anything fancy. Under XFree86 I relied on Xinerama. Summit manages it itself (it has a xinerama extension too). Windows manages the dual screen however it does.
It’s just a plain old GLCanvas (created by the factory) in a JFrame.
FYI:
Dell Inspiron 9100 w/ 3.2GHzP4 w/ ATI Radeon 9700 Mobility
Windows XP Pro
JDK1.5 beta2
JOGL 1.0.
+
Dell Desktop w/ VP880Pro
Windows XP Pro
JDK1.5b2
JOGL 1.0
+
Dell Destktop w/ VP880Pro
Redhat Linux 9.0
XiG Summit accelerated X server
At least on Win32 machines that are dual-headed, there is no problem. I believe this is because they run a single GL context for both screens if possible. It feels like it is something the O/S is doing rather than OpenGL. Even with my setup here which uses 32bit on the main screen and 16bit on the secondary, it never seems to pick two different GL contexts in native applications. That’s with the ATI card I have in currently. I need to swap back in one of our 3Dlabs cards shortly and will see if that makes a difference.
I would be interested in the results of using two different videocards. I think we can listen for ancestor_moved events, track what graphics configuration the canvas is attached to, and force a surface relock if appropriate. Alas I don’t have the hardware to try it out.