Previous Next Tracker index See it online !

(208/245) 3931 - incorrect display scaling on MacOSX Retina (with workaround)

Summary: incorrect DPI scaling with binary, direct launch of jedit.jar works correctly

Version/Environment: jEdit 5.2.0 on OSX El Capitan
java version "1.8.0_60", Java(TM) SE Runtime Environment (build 1.8.0_60-b27), Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

When run with the jEdit.app/Contents/MacOS/jedit binary, scaling does not work correctly. While screen elements and fonts are rendered with the correct size, they appear to have been scaled up and look very ugly and pixelated. When run directly as "java -jar jEdit.app/Contents/Java/jedit.jar, this problem is not present and everything looks great. I have tried every included look&feel and they all exhibit this same behavior. Including a side-by-side screenshot comparison.

From the about screen, when run with the binary OR direct (doesn't change)
jEdit 5.2.0 server-background mode, using Oracle Corporation Java 1.8.0_60

Not familiar with the wrapper being used, so I won't guess as to the cause, but I suspect a JVM argument or environment variable disparity between the executed JRE from the wrapper, and the defaults when java is run direct from the terminal. I only have this one JRE installed.

Submitted	draeath - 2015-10-11 15:03:06.209000	Assigned
Priority	5	Labels	MacOSX specific
Status	open	Group	normal bug
Resolution	None

Comments

2015-10-11 15:51:43.972000 draeath	I should mention the example images were taken on a 220 DPI screen.
2015-10-11 18:22:50.772000 makarius	I have recently updated to El Capitan on my test machine, but it is rather old, without Retina. Maybe you want to try this alternative bundling of a jEdit-based application: http://www4.in.tum.de/~wenzelm/test/Isabelle_07-Oct-2015/ -- I would be interested how it works on such a recent Mac OS X system. Concerning the official jEdit.app, my guess is that it lacks the following Info.plist entry: <key>NSHighResolutionCapable</key> <string>true</string> E.g. see http://help.infinitekind.com/discussions/problems/4227-macbook-pro-retina-display-support
2015-10-11 18:45:33.385000 draeath	Yea, I'd thought it might be that as well, but adding to the plist file didn't appear to change anything. I think that value was used for earlier Apple-supplied JREs. There were patches flying around the Oracle bug tracker back in 2013 about it, I believe. I'll have a look at that package and see what happens with it. Download from that server is unreasonably slow, but I should be able to report back soon. EDIT: got it, trying now. I should note it appears to contain a local copy of the JRE along with a whole pile of libraries, so I may not be able to do a 1:1 test with this.
2015-10-11 19:02:53.205000 draeath	OK, that Isabelle snapshot worked out-of-the-box. I didn't need to do anything for it to pick up the proper DPI and such. I went back to jEdit, and took another look through Info.plist. In short, I wasn't able to spot anything. Specifically I removed <key>JVMOptions</key> and it's associated array element, but there was no change. This at least indicate's it's not a parameter you're passing to the JRE (from the plist anyway) that's mucking it up ;)
2015-10-11 19:12:54.135000 makarius	OK. For the record: Isabelle_07-Oct-2015 uses * NSHighResolutionCapable as explained above * jedit 5.2.0 (with minor patches) * jdk-8u60 * not the java/jfx application bundler, but the old http://java.net/projects/appbundler I actually made some experiments to use the more recent fork https://bitbucket.org/infinitekind/appbundler which also supports file associations, but it did not quite work out with an unsigned application. I actually think that the app bundler is not relevant for the retina problem, and even official jedit 5.2.0 should work with the NSHighResolutionCapable. Note that an application that has already been "seen" by Mac OS X needs to be updated as described at the end of http://help.infinitekind.com/discussions/problems/4227-macbook-pro-retina-display-support
2015-10-11 20:01:07.165000 draeath	That did the trick... and it seems doing it via the terminal wasn't enough. Finder seems to do some extra work that it just doesn't tell you about. So, yes. Inserting NSHighResolutionCapable and shuffling the .app around to invalidate this cached plist works! Looks like a simple fix for future versions, eh?