I'm trying to run a Java app (JAR file) on a high-DPI display on Windows 10. The app uses Swing and thus isn't DPI-aware. Normally when I run an application that isn't DPI-aware, Windows will scale it for me, albeit blurry. But for some reason it's not scaling the Java app; I just get a tiny little window in the corner with impossible-to-read text. How do I run a Java app with Windows' high-DPI (blurry) scaling?
-
Is it your application and do you control the sources/objects, or is it a legacy application that is now unchangeable ? – harrymc Nov 20 '15 at 14:57
-
4It's not my application; no control over the source. – Jeff Nov 20 '15 at 18:53
-
Bad news, you might need to lower your DPI to run that application. Here are some resources with hacks that might help : [Fix blurry fonts in Windows 10](http://winaero.com/blog/fix-blurry-fonts-in-windows-10/), [DPI Settings in Windows 10](http://news.kynosarges.org/2015/09/05/dpi-settings-in-windows-10/), [Windows 10 DPI blurry](http://windows10_dpi_blurry_fix.xpexplorer.com/). Create at least a system restore point backup before trying them out, just in case. The fallback solution might be to return to Windows 7. – harrymc Nov 20 '15 at 19:39
-
You could also try out [Display Changer](http://12noon.com/?page_id=80) which can change the display resolution, run the program, then restore the original settings. – harrymc Nov 20 '15 at 20:34
-
Please comment on the above comments ... – harrymc Nov 23 '15 at 08:25
-
6@harrymc How would either of the above help? The problem isn't blurry fonts or that it refuses to run, the problem is that everything is *tiny*. The "blurry" font rendering is what I *want* to achieve, and as I understood the OP's question, they do too. Setting the DPI scaling to 100% would make the whole system tiny; setting the display resolution to a non-native one would make everything look blurry. (Okay, no blurrier than on a 1080p display for me, but still.) – millimoose Nov 25 '15 at 20:48
-
1@harrymc And while the latter might make the app usable, I'm sure you understand why answering "how do I make X work on a 2160p display?" with "use a worse display" is kind of missing the point. – millimoose Nov 25 '15 at 20:49
-
In its march toward the perfect automatic display on tablets, Microsoft unfortunately doesn't much care about older desktop applications. I have listed all the known display hacks for Windows 10, because not all their effects are known, and they might be helpful if you had to reduce screen resolution or use the magnifier. Display Changer is probably the best solution by reducing resolution only for the duration of running this one app. Another would be having a secondary monitor of lower resolution. If I had a better solution, I would have put it in an answer rather than a comment ... – harrymc Nov 26 '15 at 07:27
-
2I wouldn't blame Microsoft for this. Their solution for older desktop applications is the "blurry" upscaling, and it works, even though it's not pretty. The problem seems to be that Java "claims" it can handle a high-DPI display, or otherwise insists on working with physical pixels, as opposed to an upscaled abstraction, but then does is not quite able to cash the checks it's written. (At least for Swing applications.) That's why I was kind of hoping there's a solution on the Java side of things to make it stop pretending it can handle my display when it can't. – millimoose Nov 26 '15 at 09:13
-
(A sane legacy app will actually be presented with a "fake" display to render on that's the dimensions of your actual display divided by your scaling factor. A handy example of such an app would be Steam, whose seemingly incorrect hardware survey results clued me in to this. It actually seems to take some effort to land in the uncanny valley of microscopic rendering, on the part of either an app's developers or whoever made the GUI toolkit they're using.) – millimoose Nov 26 '15 at 09:21
-
The GUI toolkit the app uses is of course the problem here and dates from when hi-res monitors and Windows 10 did not exist. If it worked once in Windows 7, where the display algorithms were less automatic, you might consider downgrading, which is easy enough to do (on condition of having upgraded Windows 7 to 10). – harrymc Nov 26 '15 at 13:45
-
I'm running thinkorswim on Windows 10 and it seems to be a Java based application. Changed to system enhanced so that the app can scale to 200% on my 4k XPS which works fine for almost everything ... except hover tooltips, any ideas on those? They're microscopic right now – Malik Brahimi Feb 08 '22 at 06:19
9 Answers
Just found an easy solution on my Windows 10 machine:
- Find
java.exeyou installed. - Right click ->
Properties - Go to
Compatibilitytab - Check
Override high DPI scaling behavior. - Choose
SystemforScaling performed by:
- 1,771
- 4
- 18
- 26
-
5Best solution - I had this problem running a .jnlp file so I had to change the "C:\Program Files\Java\jre1.8.0_131\bin\jp2launcher.exe" but this worked like charm. – Dror Harari May 18 '17 at 13:49
-
1For me it was the JDK version. Found by right clicking and opening the options from the task manager in Windows 10. – Brian Knoblauch May 31 '17 at 18:32
-
3For Windows 10, running Java-based Minecraft launchers, I had to change all the installed Java versions on my system for it to work (java.exe and javaw.exe). – cyberbit Jul 10 '17 at 22:32
-
6I used a less intrusive variant. I created a shortcut for command `java -jar myJarFile.jar` and did the steps 2 to 5 on that shortcut (Windows 10, Java 8). – Julien Kronegg Aug 25 '17 at 11:41
-
Note a potential issue: When I use this to fix C.a.R. (Compass and Ruler), the startup dialog (the logo while initializing) goes to the bottom right corner on a Surface Pro 4. – SOFe Nov 28 '17 at 01:35
-
5
-
Yes, as @masterxilo says - you need to make this change to both java.exe and javaw.exe to affect all various java apps that may run on your system. – Gal Mar 18 '18 at 04:48
-
Excellent, a really elegant solution. I had an issue with a web initialised program so for me the exe was `jp2launcher.exe` found in the jre
\bin folder. – Edward Comeau May 17 '18 at 13:47 -
This seems to work if all monitors are scaled the same amount. But if you have the main monitor at 150% and second monitor at 100%, it will come up right if it first comes up on the main monitor (even if moved to the second), but be broken if it first comes up on the second monitor (regardless if you move it to the main one). Still, better than being broken everywhere... – LightCC Nov 16 '18 at 05:54
-
-
Also to note it also worked for me on a jave-based executable, `MySQLWorkbench.exe`. I'm thankful for finally unblurry text! _(I haven't yet tested LightCC's warning about 2 monitors with different resolutions.)_ – Daryn Feb 09 '20 at 14:01
-
Any way to do this on certain Java apps, but not others? Such as through a command line Argument? – Jack Cole Apr 22 '20 at 00:42
The problem here seems to be that Swing is by default claiming that it is DPI aware, so windows doesn't scale it. Use this switch to turn off this behavior and windows will start scaling your swing app:
-Dsun.java2d.dpiaware=false
[EDIT: Unfortunately, this flag no longer seems to work in Java 8, I was testing it in Java 6. Looks like this is a known issue.]
[EDIT 2: You can modify a Java 8 install to work correctly, using a program to modify the EXE manifests. I changed the setting from true to false in the manifests inside of java.exe and javaw.exe, and now my Swing programs scale correctly in Windows 10 high dpi. I used Resource Tuner to this.]
[Edit 3] Just use Java 9
- 616
- 6
- 7
-
Can you elaborate on the edit #2? Which setting did you modify in the manifest, exactly? – Tomalak Nov 11 '16 at 14:56
-
1
-
That's the point. I've seen that flag and I set it to `false`, but the application (JNLP/WebStart) did not scale properly either way. Can you think of a simple way to cross-check whether this works or not, e.g. a test app that you know of that responds to this setting? – Tomalak Nov 17 '16 at 17:45
-
Webstart is particularly finicky because it can be hard to pinpoint exactly which executable in which jre distro you have installed you end up using. As a cross-check, I'd try launching your app directly with java.exe or javaw.exe and skipping JWS to see if there's a difference. – CarlG Dec 05 '16 at 14:39
-
There's only one JRE installed. But I get a sinking feeling that the app screen actually is implemented as an image with sensitive areas as "buttons" (much like image map in HTML) and that it therefore won't scale no matter what I do. – Tomalak Dec 05 '16 at 16:15
-
Just wanted to add that if you have a java application which has been packaged up as an exe with a jre (so you don't have to install java) this works wonderfully - specifically changing the dpiaware flag to false in the packaged java.exe and javaw.exe – stoves Mar 15 '17 at 02:24
-
6This is somewhere between comical and farcical. The framework mis-reports its capabilities and the switch that fixed the error is removed. The only work-around? For end-users to buy a 3rd party tool. And people wonder why Java has such a poor reputation. – Basic Aug 01 '17 at 12:52
-
The linked issue for the first edit is for OpenJDK. This flag works fine for me on Oracle Java 8. – Justin Smith Aug 10 '17 at 19:14
-
No need for a special tool, a simple [hex editor](https://mh-nexus.de/en/hxd/) will do to edit the java(w).exe, just take care to *overwrite* instead of insert. Never failed me. Mind though that things change in Java 9: E.g. on a 200% scale system, your Graphics2Ds will come with a scale of 2 right away (not those of your BufferedImages, though). You can getTransform, setToScale(1,1) the return value, and then setTransform with that changed transform to get to scale 1 if you absolutely want to. – Dreamspace President Oct 08 '17 at 06:29
-
After more research, I created a [class](https://stackoverflow.com/a/46630710/3500521) for devs *who do their scaling manually* (e.g. for custom components and custom graphics) that should be applicable to scaling problems independently of whether Java 8 or Java 9 is used. – Dreamspace President Oct 08 '17 at 12:13
-
I found that for some applications it is necessary to run java with the following command line: `"*Your_Path_To_Java*\javaw.exe" -Xms256M -Xmx512M -noverify -jar *YOUR_FILE.jar` . Run such command in the directory where *YOUR_FILE.jar is located. More details [can be found here](https://github.com/magarena/magarena/issues/795) – 1NN Dec 19 '17 at 13:20
-
WARNING: we've just discovered that if you 'hack' your JDK to make it high-dpi compliant (using the Resource Tuner method described above for exemple), then it may not be recognized by default by your Antivirus (which has some preconfigured whitelist of exe) and in some case it may considerably drag down the performance. In our case, with a lot of threads, our app was unusable after 'hacking' the JDK... – Francois Marot Jan 10 '18 at 10:09
-
If you stumbled across this question but are actually looking for a solution that works on Linux, this is for you.
If you can add parameters to the java binary which launches the application, you can use the option -D to pass a value for the sun.java2d.uiScale proprty to specify a scaling factor for Java2D. This will scale your application. The scaling factor value is a double. Make sure that you pass this option to the java binary itself, not the launched Java application.
Example: Launch NearInfinity.jar with a UI scaling factor of 2.5
java -Dsun.java2d.uiScale=2.5 -jar ~/jars/NearInfinity.jar
Alternatively, you can set the GDK_SCALE environment variable. Example:
GDK_SCALE=2 java -jar ~/jars/NearInfinity.jar
I found this ArchLinux Wiki article quite useful in general for running Linux on HiDPI systems, and some of the things might work on Windows as well.
- 609
- 5
- 9
-
1This is good, though I wish I could get a scaling of 1 for JFrames and the system scaling for JOptionPanes. – NateS Aug 11 '18 at 13:01
-
1
-
@AtteJuvonen Instead of just telling "my car doesn't work", when it doesn't work for you, why don't you post a new question describing what you've tried, what was the expected result, what was the actual result, what command line you've used, and what, if any, error messages you got? – Christian Hujer Sep 27 '18 at 05:51
-
@ChristianHujer I tried launching my Java Swing app with that parameter (same command line as the one in your answer, except path to jar is different) and the app was launched without scaling. – Atte Juvonen Sep 27 '18 at 11:55
-
Sorry if I seem rude, just frustrated when nothing works. FWIW I did post a new question on this and I will also post a bounty on it as soon as the site allows me. – Atte Juvonen Sep 27 '18 at 11:56
-
@AtteJuvonen I've tried to find your question. I've checked the following profiles of yours: stackoverflow, superuser, askubuntu, unix. If it is there, I must have missed it. If you copy the URL of your question here, that might help. – Christian Hujer Sep 27 '18 at 12:43
-
@ChristianHujer https://stackoverflow.com/questions/52519777/java-swing-app-still-looks-tiny-on-high-dpi-screen – Atte Juvonen Sep 27 '18 at 18:35
-
From what I can tell, `uiScale` must be an integer; I tried setting it to 1.5, but it had no effect; setting it to 2.0, however, did double the size. Running the Chatty twitch client on openjdk 14. – Paul Brannan Apr 13 '20 at 15:27
-
1
-
1This did not work in my case using Java 8, but it did work using Java 14 (only tested these two versions) – tobias.h Jul 26 '20 at 15:50
Solution: Run it on JRE 9.
This is because the Java runtime declared itself to be "DPI-aware" but didn't really supported it for AWT and Swing. Java applications were sized and rendered based on pixels rather than being properly scaled, this included HiDPI displays. Anyways, this has been recently solved. See the issue JEP 263: HiDPI Graphics on Windows and Linux and the upgrade.
So, increasing the font size does not work (because it does not increase the rest of the things); the jvm argument -Dsun.java2d.dpiaware=false does not work (because it is not really supported); and the manifest file + registry edit (for Windows) just does not work.
Then, You need to run it on JRE 9 because it really supports this feature.
- 251
- 2
- 4
-
-
4This fails to point out you have to recompile the code. Simply running the same Java 8- application on Java 9+ won't change the behavior – Ramhound Aug 01 '17 at 01:25
-
Running HiDPI programs on Java 9 solves *a lot* of problems. goo.gl/3zmL7b – Gernot Sep 23 '17 at 17:45
-
4@Ramhound You don't have to recompile. I just built a jar with JDK8 for Java 8 that overrides a fullscreen JPanel's paint() method on a W10 system with 4K screen and 200% scale setting. Run with the java.exe of Java 8, the Graphics2D object given to the method has a scaling of 1, and the JPanel has a getWidth/height of 3840x2160. Run with the java.exe of Java 9, the scaling is 2 and the width/height is 1920x1080. – Dreamspace President Oct 08 '17 at 06:48
-
@DreamspacePresident Exactly what I thought. This is because JREs are usually backwards compatible, meaning that code built on Java 1.4 will run on Java 5, 6, 7, etc; whereas JDKs are usually forwards compatible, meaning that code compiled for Java 1.5 do not necessarily compile for 1.4 or earliest versions. – Sergio Muriel Oct 09 '17 at 21:45
-
@SergioMuriel Huh, I don't understand. Really, I don't see how what you're saying is on topic or logical - but, really, this could be me, I sometimes have that. Could you help me understand? – Dreamspace President Oct 11 '17 at 15:49
-
@DreamspacePresident I give you some useful links: https://en.wikipedia.org/wiki/Backward_compatibility https://en.wikipedia.org/wiki/Forward_compatibility https://stackoverflow.com/questions/4692626/is-jdk-upward-or-backward-compatible – Sergio Muriel Oct 11 '17 at 19:08
-
1You'll find a new method in Java 9: Screen.getPrimary().getOutputScaleX(); which actually does work. (The other option is to use JavaFX screen size, (Screen.getPrimary().getVisualBounds()) which does work, and divide this against Toolkit.getDefaultToolkit().getScreenSize(), You'll find that you can get a guess at the DPI selected: 200% will result in about 2.0, but unfortunately 125% still results in a 1.0 Scaling percentage. However, even after moving to Java9: I found my GUIs all utterly destroyed as the buttons expanded, but some of the constants (used for gaps, padding etc). didn't. – wax_lyrical Dec 20 '17 at 12:57
-
-
Running Java 10 still left my GUI's horribly distorted; even straight horizontal and vertical lines changed between 1 and 2 pixels across their length. I had to [modify the javaw.exe compatibility properties](https://superuser.com/a/1207925/15844) (changing the shortcut compatibility properties also works). – Lawrence Dol Oct 18 '18 at 19:07
-
2@wax_lyrical no need to do guesswork; the necessary API actually is there for a very long time. Get a `GraphicsConfiguration`, either using `GraphicsEnvironment.getLocalGraphicsEnvironment() .getDefaultScreenDevice() .getDefaultConfiguration()` to get the default or just `.getGraphicsConfiguration()` on an actual, visible AWT `Component`. Then, you can invoke `.getDefaultTransform()` to get the transformation whose scaling component reflects the setting. If you need to deal with `BufferedImage` etc, needing pixels, apply the transformation to the size, then use identity for painting to screen. – Holger Mar 07 '19 at 13:24
-
@wax_lyrical I know, the comment was old, but it may still affect existing software. After all, this is why these Q&As are kept for future readers. – Holger Mar 11 '19 at 09:02
To force all java executables to have "properties > compatibility > dpi scaling mode" set to "System", in an administrator powershell (win-x, a), run:
$javaexes = (Get-ChildItem -path "$env:ProgramFiles\Java","${env:ProgramFiles(x86)}\java" -filter java?.exe -recurse | Where-Object {$_.Name -match "java(|w).exe"} ).fullname
$javaexes | foreach {REG ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /V $_ /T REG_SZ /D "~ DPIUNAWARE" /F}
to undo:
$javaexes | foreach {REG delete "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /V $_ /f}
Instead of HKCU you could use HKLM, but then you cannot change the dpi-scaling setting manually anymore in the properties > compatibility dialog of the java*.exe files.
- 498
- 7
- 7
You need to set PreferExternalManifest in regedit and create custom manifests for java.exe and javaw.exe as given in following stackoverflow answer https://stackoverflow.com/a/39372897
- 41
- 1
-
4Good news, the Fall Creators update allows you to change scaling behaviour by right clicking on the item, selecting properties and then the compatibility tab. Creating a custom external manifest is no longer needed - which is nice. – Richard Dec 19 '17 at 16:26
Elderry's solution is good, but what if you want to run a jar file on Windows and it doesn't have compatibility options?
Go to C:\Program Files (x86)\Java\jre\bin and find javaw.exe. Right click, properties, compatibility tab, check "override high DPI scaling behavior" and select "System" (Note that "System enhanced" did not work for me).
Now jar file windows should scale properly with readable text. If not, it might mean that Windows doesn't link jar type files to javaw.eve like it should. A third party fix is available at: https://johann.loefflmann.net/en/software/jarfix/index.html
- 11
- 2
Try Java 10.
I found that -Dsun.java2d.dpiaware=false does not work in Java 9 or 10. Also for Java 8 and 9 my swing app is small, but Java 10 sizes properly in windows!
so for an app that you can run from a bat file like: java -jar xxx.jar
I just added JAVA_HOME=....\java_10 and PATH=%JAVA_HOME%\bin;%PATH% in the bat file.
java -jar xxx.jar
- 111
- 1
I was able to get sensible dpi when ran using command prompt like:
%SystemRoot%\system32\cmd.exe /C C:\your.file.path\yourJarFile.jar
- 89,133
- 25
- 207
- 233
-
This does not answer the question really, and it does not change any High DPI settings of `java.exe` or `javaw.exe`. – Alexey Ivanov Oct 14 '19 at 17:13