Screen resolution hdpi confusion

Hello, semi noob here. I recently switched from a win10 1920x1080 laptop to an m1 MacBook. I made a lot of sketches with size(1080,1080) last year. these displayed nice on the hd screen, but with the MacBook apparently behaving as 1440x900 (and its actually a 2560x1600 screen?) I cannot preview the sketches properly + they look ugly as hell upscaled. now I read a bit about pixelDensity etc. but it’s still confusing the hell out of me… is there a simple way to just have the processing render being displayed as ‘true’ 1080x1080 on this screen? if possible, without really having to adapt the sketches? thanks!

Hi @fish233 ,

From the documentation of the pixelDensity() method :

This function is new with Processing 3.0. It makes it possible for Processing to render using all of the pixels on high resolutions screens like Apple Retina displays and Windows High-DPI displays. This function can only be run once within a program and it must be used right after size() in a program without a setup() and used within setup() when a program has one. The pixelDensity() should only be used with hardcoded numbers (in almost all cases this number will be 2) or in combination with displayDensity() as in the third example above.

So you can set it to 2 to use your HDPI display :yum:

void setup() {
  size(100, 100);

void draw() {
  // ...

Hey @josephh , thanks for your reply! I just tested with an empty sketch.
void setup(){ size(900,900); };
void setup(){ size(900,900); pixelDensity(2); };
give the same window size over here… I’m really confused

edit: double checked with some old sketches, does not work over here :confused: pixelDensity(2) doesn’t change anything. could this be Big Sur/M1 related?

Ok yes this is confusing I admit, from the pixelWidth() documentation page :

When pixelDensity(2) is used to make use of a high resolution display (called a Retina display on OS X or high-dpi on Windows and Linux), the width and height of the sketch do not change, but the number of pixels is doubled. As a result, all operations that use pixels (like loadPixels() , get() , set() , etc.) happen in this doubled space. As a convenience, the variables pixelWidth and pixelHeight hold the actual width and height of the sketch in pixels. This is useful for any sketch that uses the pixels[] array, for instance, because the number of elements in the array will be pixelWidth*pixelHeight , not width*height .

So it looks it’s only affecting functions that directly manipulate pixels and I suppose shape functions are not affected…

Maybe someone else can clarify on that?

Can you also try to print out the result of displayDensity() after setting the pixel density?

quickly checked (need to grab some sleep): displayDensity() prints out 2, regardless setting pixelDensity(2) or not.

but since I’m using a lot of shapes/primitives in those older sketches i fear this might not be really useful for me. ideally a global render window scaling factor would be really nice (and maybe more convenient)

you can still use the scale() function to do that tought :wink:

ok wait, but I render all my animations as image sequence in png/tiff, if I’m using scale() these are going to be scaled too right? I want those to be 1080x1080 and preferably the render window displayed as ‘true’ 1080x1080 so it fits my screen :slight_smile:

ok I found some semi workaround. setting display scaling to 1680x1050 (highest possible) in display settings only 30px get chopped off. also tried this GitHub - avibrazil/RDM: Easily set Mac Retina display to higher unsupported resolutions but does not seem to work here. still kinda feels lame that a 600$ win10 laptop can display 1080x1080 window without probs but the triple priced MacBook can’t.

Hence i think it would be really nice if the render window could be ‘unscaled’ relative to hdpi screens, being displayed at true screen pixel resolution.

1 Like

just found out, in openFrameworks there is a ‘High resolution capable’ bool flag in build .plist, this does exactly what i would like. Don’t know how feasible this is but would be really nice to have this in Processing too!


I met exactly the same problem on surface pro 7. I think there should be a flag like this indeed.