Since Windows and Linux no longer use FSEM with Present in the PDE, users
may want an option to re-enable it. Or Mac OS X users may want the option
to disable it (and set the LSUIPresentationMode of Processing.app themselves).

What is Processing doing to present full screen on Linux?

In GNOME 2.22.3 (as on Ubuntu Hardy 8.04) + 1.4.0.90, the current method I
believe can cause an issue. Assuming you're just making a full-screen,
undecorated window, things like the silly GNOME panels will float on top of
the sketch, unless I'm mistaken. (That's certainly the behavior I'm seeing
here.)

Is there a way to force full-screen mode?

I think even having it as an option (as with --present) would be
sufficient, But ideally, you'd want to add to the PDE? (I'm trying to learn
about how these fullscreen modes work, and how they work in different WMs,
so happy to investigate, just don't want to duplicate work.)

Right, so implementing this enhancement would fix the problem you're seeing.

I didn't realize the gnome panels were floating above (I wonder if that's
changed), so perhaps the priority on this gets bumped up a bit.

To confirm:
Full-screen exclusive mode is needed when using GNOME.

GNOME panels float above the window. Undecorated works (using --present),
but "--exclusive" currently has no effect vs. --present, even with a window
the size of the screen positioned at 0,0 and size(w,h) as large as the full
screen.

Furthermore, the panels break window positioning (half of the source of the
whole problem): 0,0 is positioned in GNOME just below the top panel.

Further clarification from Ben:
"Undecorated never replaces the menubar on the Mac, you can thank Steve for
that. That's why we have to set LSUIPresentationMode in exported
applications (which can't be done programmatically on code launched from
Processing). It's also why we use FSEM for present on the Mac, but not on
Linux or Windows when running from the PDE. Though it sounds like we need
to do FSEM for Linux from the PDE as well (which gets back to the bug)."

At this point I'm not sure whether FSEM just isn't kicking in properly on
Linux (an error in PApplet.java) or whether Java isn't playing nice (a JDK
problem) or it's the window manager (disallowing or not supporting FSEM),
but haven't had time to track it down. I hope to be able to get it fixed in
the next week or two along with the Pittsburgh event.

This appears to be a problem in Sun JDK.
https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/154613

However, I've found a thread that suggestions that using setResizable(true)
can function as a workaround.

Of course, that makes this actually quite similar to the problem on Mac.

I'm going to take a different tack and research how this is handled in
jMonkeyEngine, which manages to switch resolutions, as well; it's possible
that for heavier-duty use what people will really want is a library. On the
other hand, jME assumes a FSEM and won't work for people who want multiple
display outputs.

But the core function here is that --exclusive should be --exclusive, and
even if the source of the problem is a bug in JDK, it's only a useful flag
if it does *something*. So I'm going to continue trying some different
stuff within the current way of doing things to see what does function.

Although that seems to be fixed in Java 6u10:
http://bugs.sun.com/view_bug.do?bug_id=6636469
(I remember digging through this thread at one point.)

So there seems to be something else going on...

I'll test Java 6u10; I'm still on update 7 as I'm using the default
packages for Hardy. I'd have to build JDK u10 manually, I think.

I can get it working once Compiz is switched off. That makes sense: Compiz
is compositing the screen as multiple layers, and JDK's context isn't
getting rendered last, the Panels are.

noCursor() still largely doesn't work for me, which may also be
--present-related; here (unlike in bug 1177) it actually freezes execution
of the whole program, I think perhaps because things aren't being
initialized in the proper order. I did actually see it work correctly a
couple of times, which makes me even more suspicious. This again seems
JDK-related.

I'm going to try u10; I'm on u7 as that's the stable package for Hardy.

K, there's also a u12 out there too, and a u14 EA as well.

Also, I'm planning to update the included JRE to u12 for Windows and Linux
in a release sometime soon.

*** Bug 1190 has been marked as a duplicate of this bug. ***