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

write fullScreen() reference (plus some size() and smoothing updates) #250

Closed
benfry opened this Issue Jun 6, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@benfry
Member

benfry commented Jun 6, 2015

Variations:

  • fullScreen() uses the default renderer
  • fullScreen(P3D) uses OpenGL 3D
    • uses the display set in the Preferences window
  • fullScreen(P3D, 2) opens an OpenGL window on the 2nd display
    • this overrides the Preferences window setting
    • displays are numbered starting with 1
    • see prefs window for numbering
  • fullScreen(P3D, SPAN) opens a 3D drawing context that spans all available displays

Other points:

  • don't mix size() and fullScreen() in the same sketch. It's not (currently) prevented, but results will be inconsistent and difficult to predict.
  • the size(), fullScreen(), smooth(N), and noSmooth() methods are special
    • inside the PDE, they can only be used inside setup(). behind the scenes, they're moved to the settings() method, which happens before the sketch even runs.
    • when outside the PDE, move those methods to a public void settings() function, instead of public void setup()
@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 6, 2015

Member

Thanks!

Member

REAS commented Jun 6, 2015

Thanks!

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 7, 2015

Member

Just realized I hadn't added fullScreen() (with no arguments). Now fixed.

Member

benfry commented Jun 7, 2015

Just realized I hadn't added fullScreen() (with no arguments). Now fixed.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 7, 2015

Member

The only quirk with fullScreen() is that we don't have fullScreen(1) to indicate the default renderer on display 1... Or should we add that?

You'd have to write fullScreen(JAVA2D, 1). This is in keeping with us not screwing around with the ordering of arguments in functions (add only, don't change order or meaning) throughout the API, but seems gross. Especially because JAVA2D may be replaced by FX2D soon, and I don't really ever want anyone seeing the default renderer name anyway.

Sounds like we need fullScreen(1). What do you guys think?

Member

benfry commented Jun 7, 2015

The only quirk with fullScreen() is that we don't have fullScreen(1) to indicate the default renderer on display 1... Or should we add that?

You'd have to write fullScreen(JAVA2D, 1). This is in keeping with us not screwing around with the ordering of arguments in functions (add only, don't change order or meaning) throughout the API, but seems gross. Especially because JAVA2D may be replaced by FX2D soon, and I don't really ever want anyone seeing the default renderer name anyway.

Sounds like we need fullScreen(1). What do you guys think?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry
Member

benfry commented Jun 7, 2015

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman Jun 7, 2015

Member

Yup, I agree we do need fullScreen(displayNumber). It's adding more which we always hate to do, but we've got to spend money to make money. Beginning users should always be able to live under the convenient fiction that there are no such things as renderers.

fullScreen();   // just do fullscreen
fullScreen(1);  // display 1
fullScreen(SPAN); // span all displays

Am I right that 0 is the default display? I think we should be clear in the documentation b/c if we use fullScreen(1) as example code, users may mistakenly think that display 1 is the "main" display.

Member

shiffman commented Jun 7, 2015

Yup, I agree we do need fullScreen(displayNumber). It's adding more which we always hate to do, but we've got to spend money to make money. Beginning users should always be able to live under the convenient fiction that there are no such things as renderers.

fullScreen();   // just do fullscreen
fullScreen(1);  // display 1
fullScreen(SPAN); // span all displays

Am I right that 0 is the default display? I think we should be clear in the documentation b/c if we use fullScreen(1) as example code, users may mistakenly think that display 1 is the "main" display.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 7, 2015

Member

Ok, will add the version w/ the display number w/o a renderer.

The displays are numbered from 1. It'd be a lot easier (in the code) to number them from zero, but I thought it was too damn weird to tell people "the first display is display zero! welcome to programming—you'll like it here!"

I can't say for certain if display 1 is always the default display. I'm fairly sure it's not (necessarily), and that the default display will be the display that's running the PDE. The numbering also probably has little to do with the numbering you see in System Preferences > Displays or the Windows equivalent.

The numbering is also going to be different between Windows, Mac OS, and Linux. It might even be different after rebooting (but I hope not). Shall I continue with other weird edge cases? There's probably more. Better that I don't write the reference.

fullScreen(0) should never be used. It's actually the same as fullScreen(SPAN). Behind the scenes, fullScreen(-1) actually does full screen on the default display. (I could swap those if preferred or, say, @codeanticode felt strongly about it.) But just like smooth(0) and smooth(1) should never be seen or used, fullScreen(0) and fullScreen(-1) are an implementation detail and should never be in any code (and are also subject to change, so we shouldn't document them as such).

Member

benfry commented Jun 7, 2015

Ok, will add the version w/ the display number w/o a renderer.

The displays are numbered from 1. It'd be a lot easier (in the code) to number them from zero, but I thought it was too damn weird to tell people "the first display is display zero! welcome to programming—you'll like it here!"

I can't say for certain if display 1 is always the default display. I'm fairly sure it's not (necessarily), and that the default display will be the display that's running the PDE. The numbering also probably has little to do with the numbering you see in System Preferences > Displays or the Windows equivalent.

The numbering is also going to be different between Windows, Mac OS, and Linux. It might even be different after rebooting (but I hope not). Shall I continue with other weird edge cases? There's probably more. Better that I don't write the reference.

fullScreen(0) should never be used. It's actually the same as fullScreen(SPAN). Behind the scenes, fullScreen(-1) actually does full screen on the default display. (I could swap those if preferred or, say, @codeanticode felt strongly about it.) But just like smooth(0) and smooth(1) should never be seen or used, fullScreen(0) and fullScreen(-1) are an implementation detail and should never be in any code (and are also subject to change, so we shouldn't document them as such).

@eric-souther

This comment has been minimized.

Show comment
Hide comment
@eric-souther

eric-souther Jun 23, 2015

OS X Yosemite has a default in Mission Control that has each display its own space (Displays have separate Spaces), which hinders the use of fullscreen(SPAN). After turning it off SPAN worked beautifully.

eric-souther commented Jun 23, 2015

OS X Yosemite has a default in Mission Control that has each display its own space (Displays have separate Spaces), which hinders the use of fullscreen(SPAN). After turning it off SPAN worked beautifully.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 23, 2015

Member

@eric-souther The next release already has code that detects that setting and warns the user.

Member

benfry commented Jun 23, 2015

@eric-souther The next release already has code that detects that setting and warns the user.

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Sep 16, 2015

Member

This is finished, it's all documented now.

Member

REAS commented Sep 16, 2015

This is finished, it's all documented now.

@REAS REAS closed this Sep 16, 2015

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