fullScreen(P2D) from an executable does not work properly

[processing-bot]

Created by: UnintelligableGoofball

Description

For me, running a program with fullScreen() works fine from the IDE, but if I export it and run it from the .exe it doesn't cover the whole screen.

Expected Behavior

This is what the program is supposed to do, and what it indeed does do if run through the IDE.

Current Behavior

However, if exported and run from the executable it displays as shown. It is not a window, and cannot be moved. It acts as though it were in fullscreen, and only closes when escape is pressed, but it does not cover the screen.

Steps to Reproduce

1.Create a program that uses "fullScreen(P2D,1);" (you have to use P2D, otherwise it gets the pixel density wrong and makes everything low res, this is covered more in the Possible Causes)

2.Export the program in Presentation Mode

3.Run the resulting .exe file

This is the code which I had problems with, I have not tried any other programs but I am fairly sure the problem is from fullScreen(P2D,1):

//controlls the time between blinks (in milliseconds) NOTE: changing this will only change the time of the first blink, to change the rest change it on line 133
int blinkTime = 280;
// controls the position of the rectangles used as "eyelids"
int lowRect = -14;
int highRect = -117;
// used in blink() to keep track of weather the eyelids are supposed to be opening or closing
int blinkPhase = 0;
// controls how many pixels the "eyelids" move at a time, values above 25 could cause the "eyelids" to go through eachother.
int blinkTravel = 10;
// controls the size of the face
float scaleVal = 2;

void setup(){
  // boring well documented setup stuff
  noCursor();
  frameRate(40);
  fullScreen(P2D, 1);
  fill(0);

  // strokeWeight() at higher values convinently has rounded edges by default, so for the mouth we can just draw a line
  strokeWeight(15);
}

void draw(){
  // puts 0, 0 in the middle of the screen, keeps things centered with different sized screens
  translate(width/2, height/2);
  
  background(230, 115, 225);
  scale(scaleVal);
  fill(0);
  strokeWeight(15);
  stroke(0);
  
  //draws the face
  basic();
  // makes it blink every 300 milliseconds
  blink();
}

void basic() {
  // draws a basic, emotionless face
  line(-22, 40, 22, 40);
  circle(-75, -40, 35);
  circle(75, -40, 35);
}

void blink() {
  pushMatrix();
  noStroke();
  fill(230, 115, 225);
  
  rect(-125, lowRect, 250, 35);
  rect(-135, highRect, 250, 50);
  popMatrix();

  if(blinkTime < 1){
    if((lowRect >= -40) && (blinkPhase == 0)) {
      lowRect -= blinkTravel;
      highRect += blinkTravel;
    } else if (( lowRect <= -40) && ( blinkPhase == 0)) {
      blinkPhase = 1;
    } else if((lowRect <= -40) && (blinkPhase == 1)) {
      //delay(250);
      lowRect += blinkTravel;
      highRect -= blinkTravel;
    } else if ((lowRect < -14) && (lowRect > -40) && (blinkPhase == 1)) {
      lowRect += blinkTravel;
      highRect -= blinkTravel;
    } else if ((lowRect == -14) && (blinkPhase == 1)) {
      blinkPhase = 0;
      blinkTime = 300;
    }
  } else {
    blinkTime--;
  }
}

Your Environment

• Processing version: 4.0b8
• Operating System and OS version: Windows 11 version 21H2 (though I suspect you will have this issue on other windows 11 versions)
• Other information: Monitor is 1080P

Possible Causes / Solutions

I suspect that this is related to another issue I ran into where if I did not specify P2D in fullScreen() and ran it from the excecutable it got the pixel density wrong and made everything really low resolution, but at least that covered the whole screen. (Some digging on forums lead me to including P2D.) My theory is that if before I included P2D it was low res, but basically stretched to cover the whole monitor, then now that it accurately knows the pixel density it might be the same size image, just shrunk down to the right pixel density.

[processing-bot]

Created by: dev01111

Please can you format your code using backticks like this and also tabs/spaces:

```
// your code here
```

then it will look like

// controls the position of the rectangles used as "eyelids"
int lowRect = -14;
int highRect = -117;
// used in blink() to keep track of weather the eyelids are supposed to be opening or closing
int blinkPhase = 0;
// controls how many pixels the "eyelids" move at a time, values above 25 could cause the "eyelids" to go through eachother.
int blinkTravel = 10;
// controls the size of the face
float scaleVal = 2;

void setup(){
  // boring well documented setup stuff
  noCursor();
  frameRate(40);
  fullScreen(P2D, 1);
  fill(0);

  // strokeWeight() at higher values convinently has rounded edges by default, so for the mouth we can just draw a line
  strokeWeight(15);
}

void draw(){
  // puts 0, 0 in the middle of the screen, keeps things centered with different sized screens
  translate(width/2, height/2);
  
  background(230, 115, 225);
  scale(scaleVal);
  fill(0);
  strokeWeight(15);
  stroke(0);
  
  //draws the face
  basic();
  // makes it blink every 300 milliseconds
  blink();
}

void basic() {
  // draws a basic, emotionless face
  line(-22, 40, 22, 40);
  circle(-75, -40, 35);
  circle(75, -40, 35);
}

void blink() {
  pushMatrix();
  noStroke();
  fill(230, 115, 225);
  
  rect(-125, lowRect, 250, 35);
  rect(-135, highRect, 250, 50);
  popMatrix();

  if(blinkTime < 1){
    if((lowRect >= -40) && (blinkPhase == 0)) {
      lowRect -= blinkTravel;
      highRect += blinkTravel;
    } else if (( lowRect <= -40) && ( blinkPhase == 0)) {
      blinkPhase = 1;
    } else if((lowRect <= -40) && (blinkPhase == 1)) {
      //delay(250);
      lowRect += blinkTravel;
      highRect -= blinkTravel;
    } else if ((lowRect < -14) && (lowRect > -40) && (blinkPhase == 1)) {
      lowRect += blinkTravel;
      highRect -= blinkTravel;
    } else if ((lowRect == -14) && (blinkPhase == 1)) {
      blinkPhase = 0;
      blinkTime = 300;
    }
  } else {
    blinkTime--;
  }
}

You should often practise these, because they make code easier for others to read.

thanks, @dev01111

[processing-bot]

Created by: UnintelligableGoofball

I think I formatted it better. Thanks for letting me know, I'm a little new to programming.

[processing-bot]

Created by: clankill3r

I had a maybe related monitor issue with windows that had nothing to do with processing. I'm not on my windows laptop right, and it was in combination with a projector. But meanwhile, could you give me the exact type number of your monitor o I can check some things.

[processing-bot]

Created by: UnintelligableGoofball

This was on my laptop, not an external monitor, so I don't have a model number for the monitor or anything like that. It is a 120Hz, 1080p, 14 inch display if that helps.

[processing-bot]

Created by: clankill3r

Ok, if you run this in processing: println(displayWidth, displayHeight);does this match the display settings in windows?

Does it match the settings in windows?

[processing-bot]

Created by: UnintelligableGoofball

I used the "text()" function to display the resolution so it would work even when run as a .exe. When I run the program normally, through the processing IDE, it returns the correct information: 1920 and 1080. However, when I export the SAME program and run it, it shows 1536 by 864 and is noticeably low resolution.

[processing-bot]

Created by: UnintelligableGoofball

If I specify "P2D" in the size declaration and export it, it gets the pixel density correct and is no longer low resolution, but still thinks my screen is 1536 by 864. I think that might be because it checks the pixel density again when you specify P2D?

[processing-bot]

Created by: leohumnew

So, after much testing, here's what I've found:

This happens with any exported program from Processing 4 which uses fullScreen() and the P2D renderer when Windows scaling is set to anything other than 100%. This is a new issue since Processing 4, with Processing 3 it works no problem. Since Processing 4 JavaFX FX2D+fullScreen() also doesn't work, although that makes the window too big rather than too small as P2D does (and I've also tested that less).

displayWidth and displayHeight seem to output the correct screen dimensions, however width and height obviously report the smaller size of the window which P2D+fullScreen() make.

I've tested this on multiple computers, and so far can find no way around it, meaning that P2D is fairly useless at the moment if you want to cater for the (fairly likely, especially on laptops) case that someone will have Windows scaled to something other than 100%.

EDIT: displayWidth and displayHeight apparently don't consistently output the real dimensions, only sometimes...

[processing-bot]

Created by: leohumnew

I've further tested it, and had a look through the Processing source code, but unfortunately don't have the skill to work out what is breaking it. I've checked and it definitely happens with P2D, P3D, and JAFAFX (although this last one a bit differently, the window is too large rather than too small). Having Java bundled in the executable or not makes no difference.

This seems like a fairly major bug as it makes using P2D (or any renderer other than default) quite risky, breaking it for the not insignificant number of people with Windows scaled - any chance you could take a look when you have the time please @benfry ? Totally understand you probably have very limited time, but it would be amazing if you could fit in a look at this at some point! Or obviously anyone else with the expertise necessary :)

[processing-bot]

Created by: benfry

I've found the main problem here (and fixed it… the Windows scaling check was broken), but there's still a maze of things to figure out… It's a matrix of:

• Mac, Windows, Linux
• default renderer (JAVA2D) vs OpenGL (P2D and P3D) (not to mention JavaFX…)
• with the OS reporting a display density of 1 or 2 (or higher)
• with and without fullScreen()
• with and without displayDensity() set on the Processing side
• and on Windows, using multiple display magnification settings (100% and 200% for usual behavior, but also 150% and 175% to detect problems like those seen in the original post here)

Essentially, several dozen situations that we need to test to make sure everything is behaving consistently, so it's a lot of effort to get it right.

Processing 3.x had “no problem” because it just made everything tiny… So if you had a HiDPI screen, the default 100x100 sketch size was incredibly small. This wasn't too bad if you were doing fullScreen(), but it's a bad out of the box/initial experience for users sitting down with the software for the first time, or running nearly all of the examples.

The goal is to get things to behave more like macOS (and web browsers, for that matter), where the canvas is scaled to a reasonable size, but you can specify whether you want the pixels to be HiDPI.

(Edit: updated to note that the matrix is even messier than first posted.)

[processing-bot]

Created by: benfry

Added some fixes for this for 4.2. It's not perfect, and we're still likely to see weirdness, but the changes mean:

1. The original issue reported here is now resolved (fullScreen() uses the whole screen, regardless of magnification setting on Windows)
2. When running at display scaling of >150%, the display density will be set to 2. This will be a change for some who aren't used to setting pixelDensity(displayDensity()) in their sketches.
3. Default sizes for sketches should be more reasonable on Windows (i.e. hopefully no tiny sketches on HiDPI screens)

If you find a problem in how it works in 4.2, please file a new issue.