Sketches use the full screen-size with the opengl renderer _always_ run at 30fps in present
mode (at least on macos).
I know this is a very special case, but it's not an uncommon configuration.

Here's some code to reproduce the problem (just run in present-mode):


[code]
import processing.opengl.*;

void setup(){
size( screen.width, screen.height, OPENGL );
frameRate(2000);
}

void draw(){
background(0);
println(frameRate);
}
[/code]

As jeff suggested using screen.width-1 or screen.height-1 can be used as a temporary
workaround.

Original submission: http://github.com/kritzikratzi/fullscreen-p5/issues/#issue/10

Noticed that this issue was brought up recently in this thread
http://processing.org/discourse/yabb2/YaBB.pl?num=1261502939/0#7

Ouch, that sounds like a weird driver problem. Or problems in how Java is
behaving on OS X.

Has anyone tried ATI vs NVIDIA hardware on a Mac? Other versions of Java?
(e.g. Java 1.5 on OS X 10.5, or 1.6 on OS X 10.6).

I've only tried it on OS X 10.6, Java 1.6, NVIDIA GeForce 9400M

Yeah, it looks like it might be an NVIDIA problem. That code works fine on
this machine (OS X 10.6) that has an ATI Radeon HD 4870.

Of course it may still be something that we're doing, but it's not looking
good.

@fry ... okay, that is striking evidence. i would have still guessed it has something to do with
quartz (as opposed to the graphics card).

I'm so puzzled because of this:
Consider this example code, that just displays the framerate directly instead of writing it to the
console:
[code]
import processing.opengl.*;

void setup(){
size( screen.width, screen.height, OPENGL );
frameRate(2000);
textFont( loadFont( "Serif-48.vlw" ) );
}

void draw(){
background(0);
fill( 255 );
text( frameRate + "fps", 100, 100 );
}
[/code]

If you move your mouse to the very top of the screen to show the menu bar (or the bottom to
show the dock) you will see the framerate instantly goes up to ~450 fps. move the mouse
back into the sketch, wait for the menu bar/dock to disappear and it drops back to 30fps.

Yes, I've also noticed if I bring up another window (Processing PDE for
example)

Welcome to my world of debugging for Processing. :-)

What confuses me is that it's backwards from how I would expect a
full-screen exclusive mode bug to behave. It's only with OpenGL sketches,
right? What about hint(DISABLE_OPENGL_2X_SMOOTH)?

A better option might be to find a JOGL example that uses FSEM, and test
the framerate in that, so that we can figure out if it's even
Processing-related or something in JOGL, or OS X, or one of the other
hundred layers that could be going wrong.

edit]
Nasty written class to test maximum framerate with jogl-jsr231-2.0

to run this you'll need the jogl libraries from:
http://download.java.net/media/jogl/builds/archive/jsr-231-2.0-beta10/

just included all the jars you find the zip-file,
don't forget to set java.library.path!

it's easiest to run in eclipse, just add all those jar files to the build path,

then create a run-configuration and add "-Djava.library.path=lib" as a
vm-argument.

So i've done some testing.

#1: Using the jogl-version included with processing 1.0.9
60fps in windowed mode (can't seem to disable v-sync)
30fps in fullscreen excl. mode

#2: Using jogl-jsr231-2.0: (from http://download.java.net/media/jogl/builds/archive/jsr-231-
2.0-beta10/ )
900fps in windows mode
30fps in fullscreen excl. mode


So if this is an NVidia only bug it should also affect other applications....
I'm still confused, but still trying to investigate a bit further...

Probably only other Java applications that use OpenGL. My guess is that the
bug is with Apple's FSEM implementation in Java, and how it interacts with
the NVIDIA drivers. If it affected all OpenGL applications it would
probably be fixed by now.

so you think there's nothing we can do?
(because apple generally seems lazy about fixing java bugs)

Not necessarily... It would probably be worth filing a bug with them with
the test case. The fact that we've cleared that it's outside Processing helps.

Perhaps take that .java file, create a .class, add jogl.jar and the osx
natives, and write a one line sh script in a file to run the code on its
own (a single java -cp line that also sets the java.library.path to the
current folder so that it picks up the libs). Then we can make a zip of it
to file as a bug report, and submit it.

And if we don't hear anything back, we can post it to the OS X java-dev
mailing list in the hope that someone helpful there might be able to
identify something.

I posted the problem to the jogl-forums http://www.javagaming.org/index.php/topic,21891.0.html
and someone named "Al guy" suggested the following (actually working!) solution:
frame.setExtendedState(java.awt.Frame.MAXIMIZED_BOTH);

it's short and sweet :)

@jeff
This can even be used as a temporary fix:
[code]
import processing.opengl.*;

void setup(){
size( screen.width, screen.height, OPENGL );
frameRate(2000);
textFont( loadFont( "Serif-48.vlw" ) );

for( int i = 0; i < args.length; i++ ){
if( args[i].equals( ARGS_PRESENT ) ){
frame.setExtendedState(java.awt.Frame.MAXIMIZED_BOTH);
}
}

}

void draw(){
background(0);
fill( 255 );
text( frameRate + "fps", 100, 100 );
}
[/code]


@fry
One important note: This ONLY fixes the framerate issues with FSEM, i still have the same
issues when using an undecorated window with hidden menubar/dock. Maybe next week :)

but you've tried to use the same workaround for undecorated, right? and it
still pegs the rate at 30? (as opposed to just running slower than FSEM,
which i might expect anyway).

i've added the fix for the next release (whatever comes after 1.0.9).
thanks as always & keep me posted.

yea, i tried it without improvement (still at 30fps).
but i only fixed some code together i had sitting around. i'll try to play around with it in the
processing source next week or so.

yeah, i'd recommend just working on that smaller test case that's just
straight jogl + java, so that you can eliminate some variables from what
might be going wrong. you don't want to get stuck debugging a weird thread
interaction in how PApplet is handling its sleep time inside draw(), for
instance.

Filed to the Apple bug reporting black hole as #7671837.

even thouh this is closed already, here's pretty much everything i found out about the situation
from a "what can we do from within java" point of view:


1. Are we in FSEM?
Fix is easy, just run
frame.setExtendedState( Frame.MAXIMIZED_BOTH );
_after_ entering fullscreen


2. Just using a fullscreen-window with hidden menu bar.
a. are width < screen.width || height < screen.height?
nothing to do then!
b. else...
move the applet around in the window, s.t. at least 1 pixel is invisible:
applet.setLocation( 0, -1 );


this is not pretty at all, but it is how i currently work around the situation in my fullscreen-api.
it's actually a real pain...

yeah, with foolish optimism i posted the bug with apple, along with the
test case, and they keep coming back for more details: "send your system
profiler info" and now "i can't get this to work. please submit a working
application." apparently they can't be bothered to attempt getting it to
run. i might just try bringing it up on the java-dev list and see if i can
get more help.

ah, i take that back. getting this jogl 2 stuff to run is a mess. wow.

do you have the necessary magic to make it work? when including everything
i get an error like so:

Class ContextUpdater is implemented in both
/Users/fry/Desktop/jogl-2.0-macosx-universal/lib/libjogl_gl2.jnilib and
/Users/fry/Desktop/jogl-2.0-macosx-universal/lib/libjogl_gl2es12.jnilib.
One of the two will be used. Which one is undefined.

(removing the *es* stuff doesn't help, still complains about profile stuff)

or i get assorted other errors when one lib or another is included. e.g.
that the Profile isn't defined, etc etc. basically, i need the absolute
minimum set of jar files, jni lib files and terminal magic to get the thing
to work.

giving up on this one. without further info on a general way to build, and
with the low, low likelihood of apple fixing the problem, there's not much
to pursue.