Is there a way to determine display size prior to setting screen size?

Jackieh111

I'm writing a program that will run on different screen sizes so I want to dynamically set the screen size in setup. Can I find out the width and height of the attached display at run time and then set screen size? I don't want to use fullScreen as sometimes the attached display will be just too big and I want to put a max on setup size.

Any suggestions?

Andreas_Ref

size(displayWidth, displayHeight);?

GoToLoop

https://Processing.org/reference/settings_.html

void settings() {
  size(3*displayWidth>>2, 3*displayHeight>>2);
}

jeremydouglass

Following up on GoToLoop's example solution: The key point for other forum-goers unfamiliar with settings() -- it runs before setup(), and is primarily for the purpose of dynamic screen sizing, as in your question.

The settings() function is new with Processing 3.0. It's not needed in most sketches. It's only useful when it's absolutely necessary to define the parameters to size() with a variable. [...] The settings() method runs before the sketch has been set up, so other Processing functions cannot be used at that point.

• https://processing.org/reference/settings_.html

Jackieh111

Thanks for all the replies. When I print displayWidth and displayHeight I get different values than when I print width & height when I use Fullscreen. For now it doesn't matter I just hardcoded width and height in size as when I use fullscreen or displayHeight and displayWidth I'm getting timeout errors. I'm using raspberry pi & raspberry pi video with GLVideo library. I had it all working beautifully a week ago with no errors with the older raspberry pi camera but when I used a smart TV as a monitor I couldn't get the camera to work the second time I tried it. In the end the camera wouldn't work at all so purchased a new latest pi camera and since then could not get fullscreen (or displayHeight & dislayWidth) to work reliably at all. Lot of flickering and timeouts. I had the ship out the pi and camera on Friday for an install at a gallery so went went with the hardcoded size values for now. Not ideal but at least it works consistently now.

gohai

@Jackieh111 The difference between the two values could be explained by overscan on the Raspberry Pi, which is also the reason why P2D & P3D sketches sometimes appear offset to the window frame that contains them. (The reason for this is that the window manager returns one size, and the OpenGL driver returns another. I am looking to getting this fixed.) The best workaround currently is to disable overscan in /boot/config.txt, which is also what the image we're distributing has pre-set.

Curious about the camera issue you're experiencing. If you have time, you could writeup the issue on the GitHub project - I'll have a look and will try to reproduce.

In general: going from smaller display sizes to larger ones (1080p), is considerably taxing on the GPU, since it is fill-rate constrained, and needs to push out so much more pixels all of a sudden... (it's something that I am also looking into if there's anything we can do about, or if there is a bug on our side - even an otherwise empty P3D sketch won't run at a great framerate on a 1080p display).

Curious to learn about your artwork, also! (Same applies to everyone: if you make something cool with the Pi & Processing, do consider sharing it in the Forums - we'd love to see what people do with the software)

Jackieh111

@gohai I finally got back to this. I've posted issue #27 on Github. Thanks fro your help.

gohai

Thanks @Jackieh111. I'll have a look!

jeremydouglass

https://github.com/gohai/processing-glvideo/issues/27