Some shader() examples behave unexpectedly at higher pixel densities #1063

This is what I see on macos 14.6.1 M2; not sure how it's supposed to look:

This is what I see on macos 14.6.1 M2; not sure how it's supposed to look:

Hey, @vsquared I think it should look something like this:

When I try to run in linux, it's working as expected, so probably it's a mac specific issue. Mac are sometimes really weird when working with opengl.

Btw, @vsquared do you mind removing this line in the code and build again to see what you get, probably you should get the correct result then. I can't debug since I am not a user of mac.

We should probably work with shader on how it works with mac for pixel Density?

3. Notice the rendering is wrong

Hi @SableRaf , From what I can see, the Conway Game-of-Life example (https://processing.org/examples/gameoflife.html) is rendered with Processing’s default renderer. So does it actually uses any OpenGL pipeline or custom shaders?

I’ve been investigating the flickering you noted in the shader reference sketches. Even after commenting out the line that syncs pixelDensity to the display density the problem persists, so it looks independent of pixelDensity.

the shader still don't work and shows kind of flickering effect :

That makes me suspect the issue lies elsewhere. Would you agree this is independent of pixel density? If so, I can prepare a minimal example and file a new issue—just let me know if there’s anything else we should check first. Not sure if conway example we are using uses any opengl context or works on the GPU side.

This is what I see on macos 14.6.1 M2; not sure how it's supposed to look:

This is the correct appearance. The issue in question is specific to Processing 4.4.3 (the latest beta at the time of posting). We changed the default behavior so that pixelDensity matches the displayDensity. However that causes issues with some shader examples. The temporary workaround is to add pixelDensity(1) to the setup() in these examples. However, we'd like to fix the underlying issue which is that shader examples should be working regardless of pixelDensity.

If you want to investigate further, make sure you're testing on Processing 4.4.3 or building from the latest source. We suspect the issue may be related to the built-in PShader uniforms, or something in the way the shader() function is implemented.

@perminder-17 You're looking at Topics > Cellular Automata > Game of Life. This is not a shader-based example. @vsquared has the correct one which is in Topics > Shaders > Conway. As for the flickering you mentioned, it seems unrelated to this issue. Please open a new issue with details about which version of Processing you are using and the code you are running.

My mistake; I tested on Processing 4.4.1. Sorry for the confusion.

@SableRaf, i have tried to build the Processing 4.4.3 source code to test
but I can't reproduce this bug on windows! i can see the exact same pic as @vsquared posted, maybe it is macOS specific issue?

@AhmedMagedC Do you have a high-density display? Otherwise you'd need to set pixelDensity(2) manually

@AhmedMagedC Do you have a high-density display? Otherwise you'd need to set pixelDensity(2) manually

i have 1920 * 1080 screen monitor (using laptop)
is that considered high-density? anyway when i set pixelDensity(2) in setup() i see this message in console pixelDensity(2) is not available for this display and still nothing changes i see the same pic

Yeah that message indicates that you do not have a high-density display, you can go into settings -> system -> display (iirc) and change the display scaling to 200% for example. Not sure if you could work this way though

Yeah that message indicates that you do not have a high-density display, you can go into settings -> system -> display (iirc) and change the display scaling to 200% for example. Not sure if you could work this way though

is that how it looks like?

and do you mean i can't work on this issue due to not having high-density display?

is that how it looks like?

Yes @AhmedMagedC, this is what the buggy version looks like. Since you were able to set the sketch to render at pixelDensity(2) using Stef's suggested workaround, then you should be good to go for investigating the source of the bug! Thanks for your help.

is that how it looks like?

Yes @AhmedMagedC, this is what the buggy version looks like. Since you were able to set the sketch to render at pixelDensity(2) using Stef's suggested workaround, then you should be good to go for investigating the source of the bug! Thanks for your help.

Alright Thanks, I will look into it

In some of the shader examples, I can see that the coordinate system is acting like it's 1/4 of the size that it should be when pixel density is 2. This would certainly break the game of life shader example. In the Deform example, the post-processing effect output is stuck in the lower-left quadrant. I believe this could be a result of gl_FragCoord being incorrect.

I've meant to report a possibly-related situation that I've encountered when working on my Macbook with a retina display. The following sketch looks wrong and broken unless I manually set pixelDensity(1). Only the first 1/4 of pixels are rewritten with the red channel, and the rest are left unchanged. Even though the developer could account for pixel density, this feels counterintuitive - I would expect the pixels array to match the width and height of the sketch. I'm not sure how to solve this particular confusing situation, and I thought it was a bug for a while 🤦

While the shader example does seem like an issue that could be solved (I'll try to take a look into this), pixelDensity(2) seems problematic and confusing in a variety of situations.

void setup() {
  size(640, 480);
  //pixelDensity(1); // breaks w/2, the default on a macbook
}

void draw() {
  background(0);
  
  // draw a yellow rect
  fill(255, 255, 0);
  rect(100, 100, width - 200, height - 200);
  
  // make it grayscale w/pixel maniuplation.
  // broken on high-density screen 
  loadPixels();
  for (int x = 0; x < width; x++) {
    for (int y = 0; y < height; y++) {
      int loc = x + y * width;
      float r = red(pixels[loc]);
      pixels[loc] =  color(r,r,r);
    }
  }
  updatePixels();
}

Looking at the processing4 source a bit, In PGraphics.java (and PGraphics2D.java which might not be relevant to shaders), there's a block of code where UV coordinates are multiplied by the pixelDensity. I will keep looking, but this seems like a place to investigate.

    u1 *= img.pixelDensity;
    u2 *= img.pixelDensity;
    v1 *= img.pixelDensity;
    v2 *= img.pixelDensity;

    beginShape(QUADS);
    texture(img);
    vertex(x1, y1, u1, v1);
    vertex(x1, y2, u1, v2);
    vertex(x2, y2, u2, v2);
    vertex(x2, y1, u2, v1);
    endShape();

Also of note: in PGL.java, there's texCoords which is probably connected to how UV coordinates are accessible to shaders

Hi @cacheflowe! Thanks for looking into this. the pixelDensity issue has been quite a conundrum for some time. Here is another attempt made if that helps you to further explore this problem: #1145 (Not sure if you've already seen this)

Thanks @catilac for the reference!

I did some initial investigation (with help from Claude Code). It looks like the shader examples might be fixable independently of the more complex issues around get() and set().

In PShader.java, the resolution uniform currently passes logical dimensions (for example, 640×480), while gl_FragCoord operates in framebuffer coordinates (for example, 1280×960 when pixelDensity is 2). When shaders compute gl_FragCoord.xy / resolution.xy, they get values outside the 0-1 range for most of the sketch surface.

One possible approach would be to scale the resolution by pixelDensity in setCommonUniforms().

In a quick local test, this seemed to make the shader examples behave correctly at both pixelDensity(1) and pixelDensity(2) but I don't know whether this is the right fix in all cases or if there is a better approach.

@cacheflowe What do you think? If the above sounds reasonable to you, would you like to propose a PR?