New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should full screen be handled? #3296

Closed
benfry opened this Issue May 18, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@benfry
Member

benfry commented May 18, 2015

This is for @shiffman @REAS and @codeanticode but I'm posting it here so that we can have a record of our conversation (since usually it winds up lost in email, or if it happened in person, we don't have good notes).

Just hit a hitch with my genius revelation from over the weekend about how size() should be handled. Turns out that inside this new settings() method, displayWidth and displayHeight cannot be set, because the sketch doesn’t yet know 1) which display will be used (as requested in those parameters) and 2) what renderer is in use (which is used to determine the display, since each renderer has different opinions about this).

Soo… We can work around these, but I want to first ask:

Is it time to have a method called fullScreen() that you use instead of size(), when you’re going full screen? e.g.:

void setup() {
 size(displayWidth, displayHeight);
}

becomes:

void setup() {
 fullScreen();
}

or this:

void setup() {
 size(displayWidth, displayHeight, OPENGL);
}

becomes this:

void setup() {
 fullScreen(OPENGL);
}

We could even get crazy and specify the display:

void setup() {
 fullScreen(OPENGL, 1);
}

or

void setup() {
 fullScreen(OPENGL, ALL);
}

to span all displays. (I’d like something better than ALL here, since it’ll be a constant.) We could even call it fullSize() to go with size(), but that seems a little weird.

Or we could have a special width/height options for size() like so:

size(FULL_SCREEN, FULL_SCREEN);
// or
size(ALL_SCREENS, ALL_SCREENS); 

which would prevent us from having to mention fullScreen() everywhere we mention size(). Though that seems really gross.

We can also stick with the current size(displayWidth, displayHeight) syntax, where displayWidth and displayHeight work properly. Even though they’re 0 when size() runs, only the PDE needs to know that, and they’ll work the rest of the time (when the sketch is running, even the rest of setup()), and internally, we'll use width/height of 0 to indicate that it’s full screen on init.

And if we go that route, should we also add spanWidth and spanHeight (or something like that) to make a sketch span across screens?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 18, 2015

Member

The other plus for the fullScreen() method is that it's in line with a fundamental goal in the Processing API, to reduce the amount of extra chatter to do the most common things. If we're heading toward/are already in a time where at a minimum, 10–20% of sketches start with size(displayWidth, displayHeight, OPENGL), then it's time to make that syntax simpler.

Member

benfry commented May 18, 2015

The other plus for the fullScreen() method is that it's in line with a fundamental goal in the Processing API, to reduce the amount of extra chatter to do the most common things. If we're heading toward/are already in a time where at a minimum, 10–20% of sketches start with size(displayWidth, displayHeight, OPENGL), then it's time to make that syntax simpler.

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman May 18, 2015

Member

I've read this a few times and fullScreen(), fullScreen(P3D), fullScreen(P2D, 1), fullScreen(P3D, ALL) are really starting to grow on me. I think we might be able to live with this documentation-wise by adding the fullScreen() method and linking from and to size(). And then just size() stays everywhere else in the docs.

A couple questions:

1: How does this related to present mode? Does present mode go away? Do you ever want "fullscreen" with a smaller window? (I find that being able to launch sketches in windowed or present mode without changing the code to be useful, and few are aware of how to launch a sketch automatically in present mode from the code itself.)

2: Should we consider a fourth (fifth?) argument to size as another alternative?

// launch full screen at full resolution
size(displayWidth, displayHeight, P3D, FULLSCREEN); 
// launch full screen with smaller window (a la present)
size(100, 100, P3D, FULLSCREEN);
// launch full screen on display 1
size(displayWidth, displayHeight, P3D, FULLSCREEN, 1); 
// launch full screen and span? display 1
size(displayWidth, displayHeight, P3D, FULLSCREEN, ALL); 

I'm not advocating for this, just thinking out loud.

Member

shiffman commented May 18, 2015

I've read this a few times and fullScreen(), fullScreen(P3D), fullScreen(P2D, 1), fullScreen(P3D, ALL) are really starting to grow on me. I think we might be able to live with this documentation-wise by adding the fullScreen() method and linking from and to size(). And then just size() stays everywhere else in the docs.

A couple questions:

1: How does this related to present mode? Does present mode go away? Do you ever want "fullscreen" with a smaller window? (I find that being able to launch sketches in windowed or present mode without changing the code to be useful, and few are aware of how to launch a sketch automatically in present mode from the code itself.)

2: Should we consider a fourth (fifth?) argument to size as another alternative?

// launch full screen at full resolution
size(displayWidth, displayHeight, P3D, FULLSCREEN); 
// launch full screen with smaller window (a la present)
size(100, 100, P3D, FULLSCREEN);
// launch full screen on display 1
size(displayWidth, displayHeight, P3D, FULLSCREEN, 1); 
// launch full screen and span? display 1
size(displayWidth, displayHeight, P3D, FULLSCREEN, ALL); 

I'm not advocating for this, just thinking out loud.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 18, 2015

Member

Agree re: the docs. Just wanted to note that (since I'm already imagining going through looking for references of displayWidth() and size() in the technical stuff).

For your questions:

1: Present mode is a different nut. I think we limit that to the PDE, or it can be specified with --present in main() or from the command line outside the PDE.

We've been using present and full screen interchangeably, and I've been wondering whether they need to be untangled a little. I'm not sure where we go with that, maybe it's limited to what I just wrote (limit to PDE or command line). It's actually a little weird too, since I found last week that Present makes sketches run ~30% slower with the default renderer. Yay!

2: Not nuts about the extra argument, since we already have a fourth (file name with PDF and friends). This is mutually exclusive from that, so there wouldn't be conflict, but that loaded-up size() method seems to violate the API/syntax goal of simplifying the common things.

Member

benfry commented May 18, 2015

Agree re: the docs. Just wanted to note that (since I'm already imagining going through looking for references of displayWidth() and size() in the technical stuff).

For your questions:

1: Present mode is a different nut. I think we limit that to the PDE, or it can be specified with --present in main() or from the command line outside the PDE.

We've been using present and full screen interchangeably, and I've been wondering whether they need to be untangled a little. I'm not sure where we go with that, maybe it's limited to what I just wrote (limit to PDE or command line). It's actually a little weird too, since I found last week that Present makes sketches run ~30% slower with the default renderer. Yay!

2: Not nuts about the extra argument, since we already have a fourth (file name with PDF and friends). This is mutually exclusive from that, so there wouldn't be conflict, but that loaded-up size() method seems to violate the API/syntax goal of simplifying the common things.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 6, 2015

Member

Alright, we're full steam ahead with fullScreen().

Member

benfry commented Jun 6, 2015

Alright, we're full steam ahead with fullScreen().

@benfry benfry closed this Jun 6, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment