Full Screen on Linux/Ubuntu/Gnome

[spasi]

I just committed an implementation using Dbus. You can try it with the next build.

[Ciardhubh]

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.

[spasi]

Great, thanks. I'll add your code that detects compiz/dbus availability tomorrow. Wasn't sure how to do that.

<- linux noob.

[spasi]

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?

[Ciardhubh]

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.

[Ciardhubh]

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.

[princec]

Can we not find out from the Compiz guys what we should be doing?

Cas

[Ciardhubh]

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.