Hi,
I'm new to lwjgl and have been going through the tutorial on the WIKI.
For my own project I need to use full-screen mode and this is only kind-of working for me - what happens under Ubuntu 10.04 for me is that full-screen mode is entered successfully but the Gnome panels appear on top of the lwjgl full-screen canvas. Everything else renders correctly and animates very nicely and smoothly.
I had a similar issue in a different project when I did some Java2D full-screen development on Ubuntu - this was fixed for the Java2D case by making sure that you do NOT call frame.setUndecorated(true) before going into full-screen mode - counter-intuitive but it worked.
I'm not sure how to resolve this with the lwjgl Display, can anyone please give me some pointers?
LWJGL always creates (or recreates) the window after switching to full-screen mode, so I don't think it's related to setUndecorated.
...10 min later...
Seems like it's a known issue and it affects many other apps (OpenOffice fullscreen presentations notably), see this (https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/525807) and this (http://qa.openoffice.org/issues/show_bug.cgi?id=110881). Are you seeing this on a multi-monitor setup? Afaict from our code we do set _NET_WM_STATE_FULLSCREEN when it's available.
Quote from: spasi on May 11, 2010, 13:43:47
Seems like it's a known issue and it affects many other apps (OpenOffice fullscreen presentations notably), see this (https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/525807) and this (http://qa.openoffice.org/issues/show_bug.cgi?id=110881). Are you seeing this on a multi-monitor setup? Afaict from our code we do set _NET_WM_STATE_FULLSCREEN when it's available.
I have a single monitor.
I do run 64 bit and I do have Compiz enabled as per those bug reports you referred to.
And as per those reports, changing my Ubuntu preferences so as not to use Compiz fixes the issue for me too.
I can live with disabling Compiz if that's what it's going to take.
It's a shame though, I like wobbly windows. ;)
Thanks!
Ok, I'll try to look into this again when the next Ubuntu/compiz version comes out. I really can't tell from those bug reports if we're doing something wrong or if it's some bug in compiz.
Quote from: spasi on May 11, 2010, 16:17:08
I really can't tell from those bug reports if we're doing something wrong or if it's some bug in compiz.
Somebody here https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/525807 mentions that it's OpenOffice's fault because they didn't properly set some window attribute (comment #9). Later he (apparently a compiz dev) added in comment #42 that this has to be fixed in OO, if it's going to be fixed at all. So, it looks like it has to be fixed in LWJGL, which would be nice because Compiz seems to be rather popular.
After the last post in this thread, somebody added a comment on how he fixed it in OO here http://qa.openoffice.org/issues/show_bug.cgi?id=110881 (3rd last).
I've got the same issue (Ubuntu 32bit, latest LWJGL nightly). If you need any additional info or want me to run tests, I'd be happy to help. Unfortunately I've got pretty much zero experience with Linux windowing/Compiz, so I cannot try to fix it myself. It looks like LWJGL has to set some window flags that Compiz evaluates more strictly or omit some old compatibility flags. A quick grep through the LWJGL source for "_NET_WM_STATE_FULLSCREEN" only resulted in a few lines where it's set to false (never true). But that's as far as I got.
Sorry for the delay, I've just committed a fix for this, you should be able to test it with the next build.
The fix is basically not setting the _MOTIF_WM_HINTS when we're in fullscreen mode. org.lwjgl.opengl.Window.undecorated will continue to work for undecorated windows in windowed mode. Since I'm not sure how this is going to behave on non-Ubuntu/Gnome/Compiz setups, I added a new flag org.lwjgl.opengl.Window.undecorated_fs which will revert to the old behavior when specified.
Unfortunately the fix did not work for me (Ubuntu 10.04 32 bit, Compiz 0.8.4, LWJGL 2.5 #586). Display mode switches to the chosen resolution but the window remains decorated and only occupies the usual maximised-Window area (see attached screenshot, that's with fullscreen set to true).
Works if I switch from Compiz to Metacity.
Could you post your Display init code? Also, try running your game with -Dorg.lwjgl.util.Debug=true and copy/paste the command line output here.
Minimal test program that reproduces it for me (previous screenshot was from a more complex program but the result is the same with this minimal one):
package javatests;
import org.lwjgl.LWJGLException;
import org.lwjgl.input.Keyboard;
import org.lwjgl.opengl.Display;
public class LWJGLDisplay {
public static void main(String[] args) throws LWJGLException, InterruptedException {
Display.setDisplayMode(Display.getDesktopDisplayMode());
Display.setFullscreen(true);
Display.create();
while (!Keyboard.isKeyDown(Keyboard.KEY_ESCAPE)) {
Display.update();
Thread.sleep(50);
}
}
}
Console output with -Dorg.lwjgl.util.Debug=true:
Xrandr extension version 1.3
Using Xrandr for display mode switching
XF86VidMode extension version 2.2
Initial mode: 1280 x 960 x 24 @50Hz
Mode 0: 1280x960 @50
Pixel format info: r = 8, g = 8, b = 8, a = 0, depth = 24, stencil = 0, sample buffers = 0, samples = 0
Using NetWM for fullscreen window
Could not locate symbol glVertexWeighthNV
XF86VidMode extension version 2.2
This is the Display init code of the game from the screenshot above:
private void initDisplay() throws LWJGLException {
// Set display mode.
final DisplayMode[] modes = Display.getAvailableDisplayModes();
for (DisplayMode m : modes) {
if (m.getWidth() == displayConfig.getWidth() &&
m.getHeight() == displayConfig.getHeight() &&
m.getBitsPerPixel() == displayConfig.getBitsPerPixel() &&
m.getFrequency() == displayConfig.getFrequency()) {
Display.setDisplayMode(m);
}
// TODO handle case if no mode is found.
}
// Set various properties.
Display.setTitle(title);
Display.setFullscreen(displayConfig.isFullscreen());
Display.setVSyncEnabled(displayConfig.isVsync());
// Create display with or without AA.
if (displayConfig.isAntialiasing()) {
try {
final PixelFormat pf =
new PixelFormat(displayConfig.getBitsPerPixel(), 8, 16, 8, 2);
Display.create(pf);
} catch (Exception ex) {
Sys.alert("AA error",
"Failed to initialise display with anti-aliasing, trying without.");
System.out.println(ex);
Display.create();
}
} else {
Display.create();
}
}
Console output of the game:
Xrandr extension version 1.3
Using Xrandr for display mode switching
XF86VidMode extension version 2.2
Initial mode: 1280 x 960 x 24 @50Hz
Removed 0 duplicate displaymodes
Mode 0: 1280x960 @50
Mode 1: 1280x960 @51
Mode 2: 1152x864 @52
Mode 3: 1152x864 @53
Mode 4: 1152x864 @54
Mode 5: 1152x864 @55
Mode 6: 1152x864 @56
Mode 7: 1152x864 @57
Mode 8: 1152x864 @58
Mode 9: 1024x768 @59
Pixel format info: r = 8, g = 8, b = 8, a = 0, depth = 24, stencil = 0, sample buffers = 0, samples = 0
Using NetWM for fullscreen window
Could not locate symbol glVertexWeighthNV
getPathFromClassLoader: searching for: openal
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
getPathFromClassLoader: searching for: lwjgl
Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
Found 9 OpenAL paths
Testing '/home/dev/lib/lwjgl-2.5/native/linux/libopenal64.so'
Failed to load /home/dev/lib/lwjgl-2.5/native/linux/libopenal64.so: Could not load OpenAL library
Testing '/home/dev/projects/small_projects/SpaceFolds/libopenal64.so'
Failed to load /home/dev/projects/small_projects/SpaceFolds/libopenal64.so: Could not load OpenAL library
Testing 'libopenal64.so'
Failed to load libopenal64.so: Could not load OpenAL library
Testing '/home/dev/lib/lwjgl-2.5/native/linux/libopenal.so'
Found OpenAL at '/home/dev/lib/lwjgl-2.5/native/linux/libopenal.so'
XF86VidMode extension version 2.2
Another thing you can try: Install CompizConfig Settings Manager, go to Utility -> Workarounds and check Legacy Fullscreen support, then try again.
Quote from: spasi on July 05, 2010, 15:46:27
Another thing you can try: Install CompizConfig Settings Manager, go to Utility -> Workarounds and check Legacy Fullscreen support, then try again.
Activating the workaround works.
However there are some comments here https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/525807 (#9 and #64) that say the workaround might get removed in newer Compiz versions and that it may cause trouble with other applicatons. 0.9.0 has been released today (changelog doesn't mention anything though).
Tbh I don't know what else to do. Almost everyone says it's a compiz+opengl incompatibility and there's no solution for the time being. I think it's similar to Windows' aero+opengl fullscreen problem, the best thing to do is simply disable the composite manager when going fullscreen. I'm not a Linux expert but maybe there's a way to do this in LWJGL with some script or something?
Quote from: spasi on July 05, 2010, 17:32:21
maybe there's a way to do this in LWJGL with some script or something?
As a workaround one could switch to Metacity while the LWJGL app is running and later switch back to Compiz. Switching from one to the other takes a few seconds and I'm not sure if there are side-effects.
metacity --replace
run app
compiz --replace
Does anybody know how JOGL handles this? Guess I'll check if it suffers from the same issue later tonight or tomorrow morning; along with whether there's a command line option to enable that Compiz workaround.
Well, I took a look at JOGL. Fullscreen examples like GearsFullscreen (http://github.com/sgothel/jogl-demos/blob/348c43a12199e71017767930b0b42d939db47312/src/demos/fullscreen/GearsFullscreen.java) work correctly with JOGL 1.1 and 2. From the looks of it, they use AWT for the window. Then again, there is Jake2 (http://bytonic.de/html/jake2_webstart.html, a Quake2 Java port) which suffers from a similar issue as LWJGL, if run via JOGL.
I looked through JOGL's code and there's an X11 native window class "X11Window.c" (http://github.com/sgothel/jogl/blob/33a24c85dd18d851b614359bb6b19535afd56d33/src/newt/native/X11Window.c). They do set _MOTIF_WM_HINTS in there. Unfortunately I haven't found out how and if this is used at all in the AWT window or GLCanvas that's used to draw; and whether it works or not. From the looks of it, it's part of NEWT (which may or may not be a new library that creates native windows and may be related to JavaFX in some way, documentation is a bit .. sketchy). Their demos all use AWT/GLCanvas and there are no demos for NEWT (yet?) as far as I could tell.
So yeah, that didn't really help.
Another workaround is to enable the legacy fullscreen workaround in Compiz via the command line (manually or from a Java app). Of course this will stop working should said workaround be removed from Compiz. This workaround may also have unwanted side-effects with other apps. So one might want to check if it's activated and turn it off again if a user hasn't had it activated.
There are two ways to do this:
1) Using gconftool (on Gnome systems):
Get current state of Compiz workaround:
gconftool -g /apps/compiz/plugins/workarounds/allscreens/options/legacy_fullscreen
Activate Compiz workaround:
gconftool -s /apps/compiz/plugins/workarounds/allscreens/options/legacy_fullscreen -s true -t bool
Deactivate Compiz workaround:
gconftool -s /apps/compiz/plugins/workarounds/allscreens/options/legacy_fullscreen -s false -t bool
2) Using DBus (http://wiki.compiz.org/Plugins/Dbus, obviously requires DBus running):
Get current state of Compiz workaround:
dbus-send --print-reply --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/workarounds/allscreens/legacy_fullscreen org.freedesktop.compiz.get
Activate Compiz workaround:
dbus-send --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/workarounds/allscreens/legacy_fullscreen org.freedesktop.compiz.set boolean:true
Deactivate Compiz workaround:
dbus-send --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/workarounds/allscreens/legacy_fullscreen org.freedesktop.compiz.set boolean:false
I just committed an implementation using Dbus. You can try it with the next build.
Ah, I'll take a look tomorrow. Just finished my own implementation. I basically wrapped the Display class in my own. If the OS is Linux and Compiz is running, it automatically activates and deactivates the workaround if you go fullscreen or return from fullscreen. Source of my implementation if you're interested. (http://www.ciardhubh.de/download/forum/CompizLWJGLWorkaround.tar.gz)
Great, thanks. I'll add your code that detects compiz/dbus availability tomorrow. Wasn't sure how to do that.
<- linux noob.
The next build will have the improved implementation, including support for gconftool. Btw, I noticed that goconftool doesn't apply the workaround immediately. I had to add a Thread.sleep(200) to get consistent results. Could you verify that this happens with your implementation too?
Quote from: spasi on July 09, 2010, 18:48:03
Could you verify that this happens with your implementation too?
Unfortunately it does happen with my implementation too.
Gconftool immediately and consistently reports the correct value after setting it, i.e. the following JUnit test runs fine:
/**
* Test whether gconftool takes some time to apply the change.
*/
@Test
public void testGconfDelay() throws Exception {
System.out.println("testGconfDelay");
LegacyDisplay.setProvider(new GconfProvider());
LegacyDisplay.setFullscreen(true);
// Try with non-existing display.
testGconfDelayRun();
// Try with existing display
LegacyDisplay.create();
testGconfDelayRun();
LegacyDisplay.destroy();
}
/**
* Activates the workaround. Queries the state to make sure it's on. Then deactivates the
* workaround and checks again. This is repeated several times.
*/
private void testGconfDelayRun() {
boolean expResult;
boolean result;
final int testRuns = 200;
for (int i = 0; i < testRuns; i++) {
LegacyDisplay.activateLegacyFullscreen();
expResult = true;
result = LegacyDisplay.isLegacyFullscreen();
assertEquals(expResult, result);
LegacyDisplay.deactivateLegacyFullscreen();
expResult = false;
result = LegacyDisplay.isLegacyFullscreen();
assertEquals(expResult, result);
}
}However, if I take a look at the resulting fullscreen window, in about 50% of the cases of the following test I get the bug.
@Test
public void testVisualDelay() throws Exception {
System.out.println("testVisualDelay");
LegacyDisplay.setProvider(new GconfProvider());
LegacyDisplay.setFullscreen(true);
final int restRuns = 10;
for (int i = 0; i < restRuns; i++) {
LegacyDisplay.create();
Thread.sleep(1000);
LegacyDisplay.destroy();
}
}If I add a delay of 100 ms between setting the workaround and creating the display, it drops to 10%-ish (just a ballpark figure). 200ms looks good for about 40 tests. This does not happen when I use DBus.
I tested your code and it works as expected. Of course it suffers from the same issue as mine: If the VM crashes, it won't deactivate the workaround in Compiz.
For example, this leaves the workaround active if it was deactivated:
public static void main(final String[] args) throws LWJGLException, InterruptedException {
Display.setDisplayMode(Display.getDesktopDisplayMode());
Display.setFullscreen(true);
Display.create();
while (!Keyboard.isKeyDown(Keyboard.KEY_ESCAPE)) {
Display.update();
Thread.sleep(50);
}
// Crash Java VM
Object[] o = null;
while (true) {
o = new Object[]{o};
}
}
I considered writing the state to disk before changing it, to be able to recover in case of a crash. However that's not exactly reliable either (Will the program in question ever run properly again? Has the user changed his mind, i.e. does he now want the workaround to stay active? etc.). Plus it's hard to tell how long the workaround will stay in Compiz.
Can we not find out from the Compiz guys what we should be doing?
Cas :)
Quote from: princec on July 12, 2010, 18:55:15
Can we not find out from the Compiz guys what we should be doing?
Where's the fun in that? ;)
Call me jaded but that will likely result in a post in a forum or mailing list, never to be answered. This workaround might not be the best solution, but it works, now. At the least, it bridges the time until a more robust solution can be found.