Skip to content

Pixel Density Changes

Raphaël de Courville edited this page Sep 19, 2025 · 5 revisions

Since Processing 4.4.3, sketches automatically use the pixelDensity(2) on Retina/HiDPI screens. This makes graphics look sharper, but it also means that sketches doing pixel-level work may not look the same as they did in earlier versions of Processing. You may see a warning in the console about the change (see PR #1226).

When this matters

These discrepancies mostly affect sketches that use get() and set() to read or write pixels, access the pixels[] array, use custom shaders that assume a fixed pixel density, or export to SVG or PDF. The underlying issue has been around ever since pixelDensity() was introduced (see Issue #693), but it didn’t affect many people since inconsistencies would only appear on specific sketches, when manually setting pixelDensity(2). Now that pixelDensity(2) is the default for HiDPI displays, more users are running into these cases.

Demonstrating the issue

The example below shows the new behavior on a HiDPI display, with the default (pixelDensity(2)) and when explicitely setting pixelDensity(1).

Two Processing sketches side by side. The left sketch uses the default `pixelDensity(2)` and the window shows a smaller red and blue block. The right sketch uses `pixelDensity(1)` and the window shows a full-width red block on the left and a blue block on the right, as expected.

Recommendations

If your sketch behaves incorrectly on a high-DPI display, you have two main options:

  • Set pixelDensity(1) in setup() to keep the old behavior everywhere.
  • Or, adapt your code to the screen’s density by using displayDensity(), so pixel operations scale consistently.

References

Clone this wiki locally