-
-
Notifications
You must be signed in to change notification settings - Fork 100
Pixel Density Changes
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).
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.
If your sketch behaves incorrectly on a high-DPI display, you have two main options:
- Set
pixelDensity(1)insetup()to keep the old behavior everywhere. - Or, adapt your code to the screen’s density by using
displayDensity(), so pixel operations scale consistently.
We are considering a change in PR #1145 that would make get(), set(), and similar functions always use logical sketch coordinates. In practice, this means that if your sketch is 400x400, those functions would always treat it as a 400×400 grid, even on a high-DPI screen where the backing buffer might actually be 800×800 physical pixels. Processing would handle the scaling behind the scenes. However but this could introduce unexpected side effects, and some users may still want the ability to access physical pixels, so the change has not been implemented yet.
The discussion is ongoing, and feedback is welcome on issue #1131.