fullScreen() does not work for second display with P2D/P3D in certain screen alignments

[processing-bot]

Created by: HectorCarral

Description

Using fullScreen() with P2D or P3D fails to run the sketch on a secondary screen, despite specifying the display number and also regardless of the Processing settings. It always runs on the main screen.

Expected Behavior

The sketch is run fullscreen on the specified screen, regardless of the renderer used.

Current Behavior

The sketch always runs fullscreen on the main screen if P2D or P3D is specified.

For example, using a laptop with a secondary screen connected, fullScreen(1) correctly runs the sketch fullscreen on screen 1 (main one) while fullScreen(2) correctly runs the sketch fullscreen on screen 2 (secondary one). However, when specifying another renderer (fullScreen(P2D, 2) or fullScreen(P3D, 2)), the sketch runs on screen 1 (main one) while the following message is presented: The sketch has been resized from 100✕100 to 1920✕1080 by the window manager. (where 1920✕1080 is indeed the correct resolution of screen 2, different from the resolution of screen 1). This is independently of the setting of default screen specified on the Processing IDE settings. The workaround to run the sketch fullscreen on the external screen is to go into the OS settings and set that as the main screen. Please note that this is on macOS, and I have been unable to test it on other operating systems.

Steps to Reproduce

1. Have a secondary screen connected.
2. Use fullScreen() while specifying P2D/P3D and the number of the secondary screen:

void setup() {
  fullScreen(P3D, 2);
}

Your Environment

• Processing version: Processing 4.0b7 (x64)
• Operating System and OS version: macOS 12.3.1
• Other information: Apple M1 chip

[processing-bot]

Created by: sampottinger

@benfry this is working for me on macOS 11.6 Intel on current master (which includes #474).

int x = 0;

void setup() {
  fullScreen(P3D, 2);
  background(0);
  noStroke();
  fill(102);
}

void draw() {
  rect(x, height*0.2, 1, height*0.6); 
  x = x + 2;
}

and

int x = 0;

void setup() {
  fullScreen(P3D, 1);
  background(0);
  noStroke();
  fill(102);
}

void draw() {
  rect(x, height*0.2, 1, height*0.6); 
  x = x + 2;
}

I do get a resize message from window manager (The sketch has been resized from 100✕100 to 2560✕1440 by the window manager.) but it is still functional.

LMK how you want to proceed.

[processing-bot]

Created by: benfry

Ok, we'll close it as resolved with #474 for 4.0 beta 8.

And I'll suppress that message when using fullScreen().

[processing-bot]

Created by: HectorCarral

I'm afraid that I'm still having the same exact issue on 4.0 beta 8 (both Intel and M1 versions). The behavior is exactly the same as described in the original issue, except that now there's no message about the resizing of the sketch.

Both programs above by @sampottinger result in the sketch running fullscreen on the same screen (the main one, never the secondary one). I have tried different things, such as changing the default screen on preferences, deleting preferences.txt, restarting my computer, etc., but same thing.

[processing-bot]

Created by: benfry

Nuts… 

If you remove the display number from the fullScreen() command and change the “Run sketches on display…” option in Preferences, what happens? (As in, does it show up on the correct display?)

[processing-bot]

Created by: sampottinger

Dang :( - I noticed that our Mac OS versions were different. Let me upgrade (😬) mine and see if it persists.

[processing-bot]

Created by: HectorCarral

Nuts… 

If you remove the display number from the fullScreen() command and change the “Run sketches on display…” option in Preferences, what happens? (As in, does it show up on the correct display?)

@benfry I just tried this again with 4.0b8 and, with no display number specified in fullScreen() (but specifying P3D or P2D), it still always runs on the main display regardless of the display number specified in Preferences. It seems to also ignore this.

[processing-bot]

Created by: benfry

Hm, I wonder if we actually have a macOS issue with JOGL not correctly using the other display, not just a preprocessor issue.

I don't suppose the native Apple Silicon version of beta 8 helps, does it? https://github.com/processing/processing4/releases/download/processing-1283-4.0b8/processing-4.0b8-macos-aarch64.zip

[processing-bot]

Created by: benfry

Just tested on an Intel machine running Big Sur (11.6.5) and an M1 machine running Monterey (latest) and both are working fine with two displays and the example that @sampottinger posted.

Make sure the second display is plugged in before you start Processing, and give it another shot, in particular with the Apple Silicon version of beta 8.

[processing-bot]

Created by: HectorCarral

@benfry No, it behaves the same for me using that native Apple Silicon version, beta 8. I just tried everything again using it (with a fresh download) and got the same issue. If I specify P3D (fullScreen(P3D, 2) it always runs on the main display (same thing with P2D), and as soon as I remove the renderer (fullScreen(2)) it works as expected.

Very strange that it is working fine for you but not me, with what would seem to be the same OS, processor, Processing version and code. I can't think of anything in my setup that is out of the ordinary.

I have indeed tried plugging the display before starting Processing, as well as restarting my machine with the display already connected, etc., but same thing. Not sure what else to try at this point.

Also:
Perhaps this is not informative/helpful, but out of curiosity I just tried with Processing 3.5.4 and again it works well with the default renderer, but it directly crashes on execution if specifying P3D/P2D while throwing this error:

0   AppKit                              0x00007ff81abc3653 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 352
	1   AppKit                              0x00007ff81abaf5e4 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1288
	2   AppKit                              0x00007ff81abaf0d6 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 42
	3   libnativewindow_macosx.jnilib       0x000000012ebd93fe Java_jogamp_nativewindow_macosx_OSXUtil_CreateNSWindow0 + 398
	4   ???                                 0x000000010d9874c8 0x0 + 4523062472
)

[processing-bot]

Created by: HectorCarral

Just made an interesting discovery regarding one macOS display setting. And with the right configuration it does indeed work well and as expected.

It seems to be dependent on the display positioning/alignment specified on System Preferences > Displays. If my displays are arranged vertically (with my secondary display above or below my main one), the issue I described before persists. However, if my displays are arranged horizontally (with my secondary display to the right or to the left of my main one), everything works as expected.

This setup makes Processing run the sketch fullscreen as expected:

While this other setup makes Processing run the sketch on the main screen as described in this Issue (also, the position along the X axis of the second display affects how off-center the sketch appears on the main display):

[processing-bot]

Created by: benfry

Ok, unfortunately that's an upstream problem in the JOGL library, so we'll have to wait for a fix (if any). You might try reporting it there in case it's not been reported yet, or someone has a fix.

In the meantime it sounds like you'll need to tweak the layout of the displays in the panel.

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.