Set default pixel density to the display's density.

[yehiarasheed]

Description

This PR closes issue #950. The aim of this PR is to change the default value of the pixelDensity variable, represented by the pixelDensity() method to the display's density (DPI). The purpose of this change is to provide sharper rendering by default to displays that support High DPI.

Implementation

This Section is regarding the implementation itself, I'll leave it here in case it is needed later for debugging. The DPI feature is computed as follows, we are making use of the Toolkit class found in the java.awt package. I've decided to implement the DPI Computation in a separate method for modularity and easier maintenance later on as could be seen below.

import java.awt.Toolkit;

  protected int getDisplayDPI() {
    int dpi = Toolkit.getDefaultToolkit().getScreenResolution();

    if (dpi == 96 && System.getProperty("os.name").toLowerCase().contains("win")) {
      return 2;
    }

    return (dpi >= 144) ? 2 : 1;  // 2x for high DPI, 1x otherwise
  }

I've used the Toolkit.getDefaultToolkit() method to acquire the Default Toolkit, on which I invoke the instance method getScreenResolution() which returns the DPI of the display if it could be computed. This introduced a tricky case, on some windows machines, whenever the DPI of the Display is high sometimes windows defaults to a DPI of 96 sometimes as could be seen in this case. Leading us to check if the DPI is equal to 96 and the system is Windows, then assume a High DPI, else just check the DPI value. We assume a High DPI value to be greater than or equal to 144 to cover Windows and Retina macOS displays effectively.

Additionally, I've updated the PImage Constructors that make use of the init method, which sets the pixelDensity variable, to use the getDisplayDPI method instead of the default value 1.

public PImage(int width, int height) {
    init(width, height, RGB, getDisplayDPI());
}

public PImage(int width, int height, int format) {
    init(width, height, format, getDisplayDPI());
}

As well as the init method itself that has three parameters to use the getDisplayDPI method too.

public void init(int width, int height, int format) {  // ignore
    init(width, height, format, getDisplayDPI());
}

Any feedback is welcomed.

[hx2A]

Thank you, @yehiarasheed , for this PR!

What platforms have you tested this on? I suspect platform specific behavior might add some wrinkles. I'd be happy to be wrong about this. Perhaps I have been traumatized by too many MacOS issues. :(

Can you make the visibility of the new method protected and not private? The PImage class is inherited by PGraphics and therefore all renderers. It is possible others might benefit from calling this some day.

[yehiarasheed]

As it turns out, you're actually correct. After a bit more research, I've discovered that the main issue is actually with windows systems as some of them by default return a DPI of 96 instead of the actual DPI whenever the DPI is high as could be seen here. On another note, I've discovered a fault in the logic of the getDisplayDPI() method implementation that I will correct and add to the PR description so that it is visible for anyone debugging any problems later on. I am testing it on a Windows machine currently on IntelliJ as instructed. Please review and get back to me. My implementation should cover most displays although, upon research, I've discovered that using JavaFX is generally more accurate than using the Toolkit class.

[hx2A]

return (dpi >= 144) ? 2 : 1; // 2x for high DPI, 1x otherwise

Is there a risk this might need to change in the future as monitors & technology evolve?

I've discovered that using JavaFX is generally more accurate than using the Toolkit class.

What other approaches are available here? JavaFX is nice but does that require extra JavaFX jars and libraries to be available? I do like JavaFX though, good for you to look into that.

Is there a way to get the pixel density info by making a call directly to the OS? Trying to infer the pixel density from the DPI feels like a less certain approach. We can write native code for each OS to do this.

[yehiarasheed]

Is there a risk this might need to change in the future as monitors & technology evolve?

There is definitely a risk that this might need to change in the future since we’re relying on a specific number. A better approach would be us checking if the DPI is just greater than 96, so that we don’t specifically check for numbers greater than 144 (hardcoding) and we can include any display with a DPI higher than the standard 96 as high-DPI. Although, most OSes do tend to standardize scaling factors so the number 144 should work fine in most cases.

What other approaches are available here? JavaFX is nice but does that require extra JavaFX jars and libraries to be available? I do like JavaFX though, good for you to look into that.

As for the JavaFX approach, it’s generally more accurate than using the Toolkit class and would definitely need some setup and adding dependencies and JARs, still I do like JavaFX too. However, this doesn’t really matter since the best approach is actually querying the OS itself using native OS functions and getting the actual numbers, this is as good as it gets. It actually came up to me while looking through the getDisplayDPI implementation but I didn’t think we’d want to go through with such implementation. This way we would get the most accurate numbers available, directly from the OS. If we all agree on this implementation I can go ahead and change the implementation to be platform-specific and use native OS functions.

Note

Upon revision, if we decided to go with implementing platform-specific methods to get the correct pixel density, we could reuse the methods already implemented in the Platform.java file/class (Platform.isWindows(), Platform.isMacOS(), Platform.isLinux()) for maintainability.

[yehiarasheed]

Hi @hx2A , I’m adding support for detecting pixel density across platforms (Windows, macOS, Linux, Wayland). Since NativeInterface.java is in the io folder, should I create a new class for this functionality (e.g., DisplayUtils) in the core folder, or is there a better location for it?

Thanks!

[hx2A]

However, this doesn’t really matter since the best approach is actually querying the OS itself using native OS functions and getting the actual numbers, this is as good as it gets

Let's pursue this avenue and see where we can go with it.

Hi @hx2A , I’m adding support for detecting pixel density across platforms (Windows, macOS, Linux, Wayland). Since NativeInterface.java is in the io folder, should I create a new class for this functionality (e.g., DisplayUtils) in the core folder, or is there a better location for it?

Thanks!

I'm not familiar with NativeInterface.java but that doesn't seem to be a part of core.jar. Isn't that in this library?

https://processing.org/reference/libraries/io/index.html

Not everyone will be using that library though.

In core.jar you will find a ThinkDifferent.java class that already makes several native MacOS calls through a small compiled library. If there is an Objective C call that provides this information, it would be easy for you to add the code to what is already there.

For Windows there is a executable called fenster.exe that seems to be there to get the display scaling. Is that helpful for this problem? Is something about that not working?

I'm not sure about what to do for Linux. Generally Linux is better behaved about these kinds of things though.

[SableRaf]

Hey @yehiarasheed, just wondering—doesn’t displayDensity() already handle this? This PR adds quite a bit of code, so I’m curious what’s missing from the built-in solution that makes these changes necessary.

[yehiarasheed]

Hello @SableRaf,

I get that adding more code can seem excessive, but here's my reasoning:

We still need native methods:

AWT has been around for a long time, but leveraging native methods — directly calling system APIs — can provide better performance and platform-specific optimizations. This is especially important for systems where AWT is disabled or unavailable, as methods like displayDensity() may fail or behave unexpectedly (as discussed in issue #57 and the wiki). Specifically, displayDensity() relies on AWT (see PApplet.java).

Reusing Code and Adding Native Methods:

I've already reused existing code, such as Fenster.exe on Windows to get the scale factor, and added getScaleFactor() for macOS (ThinkDifferent.java and different.m). The next step is to add native methods for Linux to complete the solution.

Exploring DPI Scaling Further:

While AWT can handle pixel density, I found that Qt's approach to DPI scaling offers valuable insights. Qt also recommends using integer scaling values (1 and 2) and provides native methods for better control over DPI. They even discuss how to handle “ugly results” caused by scaling issues in their documentation.

The Challenge with Scaling Factors:

The key challenge is how to round floating-point scale factors (e.g., 1.25) to determine DPI. Should we round normally, round up to make visuals sharper, or round down to avoid assuming a high-DPI on low-density displays? Should we round in a way that biases displays with DPI greater than 1.75 to be considered equal to 2, while assuming lower values to be equal to 1? More on that here.

The Solution: Let the User Decide:

Rather than making assumptions, we could let the user choose their preferred rounding method. A default option (normal rounding) could be provided, with the flexibility for users to adjust it via methods or preferences. This would allow users to resolve any "ugly results" on their own.

Fallback Mechanism for displayDensity():

This approach could even act as a fallback mechanism for the existing displayDensity() method, ensuring that the method still functions on systems where AWT is disabled or unavailable. While displayDensity() relies heavily on AWT, this additional layer would allow it to continue providing meaningful results, preventing issues or crashes when AWT is not an option.

Furthermore, this mechanism not only addresses compatibility but also opens the door for more control and platform-specific implementations for various services. By leveraging native methods or alternative techniques, it could provide enhanced DPI scaling handling and allow for fine-tuned, platform-optimized solutions.

In conclusion, rather than being a redundancy, this could serve as a valuable fallback that ensures the continued functionality of displayDensity(), while also setting the stage for future enhancements in cross-platform support and performance optimization.

[SableRaf]

Hi @yehiarasheed. I appreciate the effort you’ve put into this!

Our long-term plan is to move from JOGL and AWT to LWJGL, and when that happens, we’ll handle DPI detection within LWJGL rather than introducing new platform-specific implementations now. To keep things simple in the meantime, we’d like to rely on displayDensity(), even if it’s not perfect.

We won’t be moving forward with this approach, but if you’re interested in contributing a minimal implementation based on displayDensity(), we’d love to see a new PR.

Thanks again for your work!

[yehiarasheed]

Hey @SableRaf,

Thanks for the feedback! I get the plan to move to LWJGL. I’ll put together a minimal implementation based on displayDensity() and send over a PR soon.

[hx2A]

And @yehiarasheed , it seems the help I was providing before was not as helpful as I would have liked it to be. I do apologize for that.

[yehiarasheed]

No worries @hx2A